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We describe how to use refactoring tools to transform a Java program conforming to the Composite design pattern 
into a program conforming to the Visitor design pattern with the same external behavior. We also describe the inverse 
transformation. We use the refactoring tools provided by IntelliJ idea and Eclipse. 
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1 Introduction 

Composite and Visitor patterns have dual properties with respect to modularity: while the Composite pattern (as well as 
the Interpreter pattern and classic class hierarchies) provides modularity along subtypes and leaves operation definitions 
crosscut, the Visitor pattern provides modularity along operations and leaves behavior definitions crosscutting with respect 
to subtypes [GHJV95]. 

One solution to have modularity along operations and subtypes would be to be able to transform automatically a 
program conforming to the Composite pattern into a program with the same behavior, but which structure would conform 
to the Visitor pattern, and vice- versa |CDA12] . 

Chains of elementary refactorings can be used to make design patterns appear [OCN99[|Ker04j . for instance to introduce 
the Visitor pattern |MT04[ lKer04| . or to replace the Visitor pattern by the Interpreter pattern [HKVDSVllj . However, 
such transformations are not fully automated yet, and our proposal of navigation between several architectures for a same 
program |CDA12| is not currently workable. 

In this report we do preliminary work before automating refactoring based Composites Visitor transformations: 

1. We give chains of refactoring operations that provide Composites- Visitor and Visitors-Composite transformations 
for a simple Java program. Each refactoring operation is supported by at least one refactoring tool. 

2. We explain how to use the refactoring tools IntelliJ idea and Eclipse to perform the needed refactoring operations 
(composition of several operations of the tools, specific options, applying some operations before being able to 
perform another one, bugs to overcome, missing operations...). 

3. We study variants of the transformations for several variations in the implementation of the patterns. 
Our algorithms are validated on a running toy example and on the JHotDraw program jGIj . 
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2 General Approach 



We consider the Java program of Fig. [T] It contains a classic class hierarchy: the abstract class Graphic has two subclasses, 
Square and Ellipse, and two methods, print and prettyprint implemented in the subclasses. We also consider that two 
classes Printer and PrettyPrinter already exist in the program: they will become visitor subclasses. 

Graphic 



print 
prettyprint (} 
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Ellipse 




Square 






print { ) 
prettyprint ( ) 


print ( ) 
prettyprint ( ) 



abstract class Graphic { 




abstract public void 


print (); 


abstract public void 


prettyprint (); 


} 





class Square extends Graptnic { 




int 1 ; 




public void print() { 

Sy stem. out. print("Square(" + 1 

} 


+ ")"); 


public void p r e 1 1 y p r i n t () { 

System. out. print(" Square." ); 

} 

} 





class Ellipse extends Graphic{ 










int 11 , 12 ; 










public void print() { 

System. out. print(" Ellipse: 

} 


(" - 


f 11 +" , 


' + 12 + 


")" ); 


public void p r e 1 1 y p r i n t ( ) { 

System. out. print(" Ellipse . 

} 

} 


" ); 









Figure 1: Base Program (classic class hierarchy) 

In the following algorithms, we make abstraction of the class and method names and number: let LM be the set 
of traversal functions, LC the set of concrete classes in the composite structure, and S the superclass of the composite 
structure. 

Here, LM = {print, prettyprint}, LC — {Ellipse, Square} and S=Graphic. 

We also define a function V that maps a name of visitor class to a name of method. We consider here y(print) = 
Printer and V (prettyprint) — PrettyPrinter. We also define LV = y(LM) ~ {V{m)}„i^iM . 

2.1 Guidelines in the Literature 

We start by considering some guidelines given in the literature for introducing an instance of the Visitor pattern into a 
typical object-oriented class hierarchy. We consider the guidelines of Mens and Tourwe [MT04) , rephrased in Fig. [51 
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1. 


ForAII m in LM, c in LC do 




Let visitorname = V{m) in 




MoveMethodWithDelegate(c, m, visitorname) 




RenameMethod(visitorname, m, "visit") 




done 


2. 


AddAbstractSuperClass(" Visitor" , LV) 


q 
o. 


rOrAM C in LL- 00 




PullUpAbstract(LV, "visit", c, "Visitor") 


4. 


rorAii c in n_ CIO 




ExtractlVlethodfc, LIVl, "accept") 


5. 


ForAII m in LM do 




PullUpConcrete(LC, m, S) 



Figure 2: Simple Class Hierarchy Visitor transformation |MT04j . 

To introduce a visitor pattern, the first obvious step is to move the business codcEl from the class hierarchy to visitor 
classes (in this section, we consider the target classes for the moved methods already exist in the project). This is done 
in step [T] (Fig. [2]). We move the business code but, in order not to change the interface of the class hierarchy, we keep in 
the class hierarchy some methods with the same profiles as the original ones, which will be delegators to visitor's methods 
(see Move Method in Fowler |Fow99) ). 

The new methods in visitor classes are named visit so that the visitor classes will all be able to implement the abstract 
class Visitor, which is added afterward (step[2|). In visitor classes, there is one method visit for each concrete class of the 
class hierarchy LC (with overloading). They are introduced as abstract methods in the Visitor class (step[3|). 

To introduce the double dispatch which is typical of the visitor pattern without changing the interface of the class 
hierarchy, another delegation is introduced inside the concrete classes of LC (step S]) . The delegate method is named 
accept. 

Since the initial methods are now delegators to accept, the overriding bodies are the same in the concrete classes of 
LC, and it can be defined once for all in the super class (step [5]). 
The refactoring results in the program given in Figs. [3]and|4l 

2.2 Automation 

If we refer to Fowler |Fow99| . a refactoring is manual with checks under the responsibility of the programmer. In the 
same way, the general guidelines given in Fig. [5] must be interpreted by someone which will adapt them to his particular 
program. 

We now consider that the programmer uses a refactoring tool. We consider IntelliJ idea but the same is also possible 
with Eclipse with small variations. 

Prepare the move. A first problem occurs with the Move Method operation. The refactoring tool cannot move instance 
methods to a class if there is no reference of the destination class in that method (in parameters or in body). The reason 
is that the receiver object cannot be inferred otherwise (we consider instance methods). 

Before moving the methods, we have to create delegates for these methods (to keep the initial interface), then add a 
parameter of the convenient visitor type to the delegates, then move them (see Fig. O step[T]). 

Restore object type after move. In our example, the pretty-print method does not access to any instance variables 
or methods (see Fig. [T]) of the receiver object. In this case, when the prettyprint delegate methods are moved, the tool 
does not make a parameter of type Ellipse or Square appear in the resulting method. 

This is problematic because we want overloaded visit methods (it's a design choice, here we could also use different 
method names) but the lack of these parameters introduces a name clash. 

To solve this, it is sufficient to apply the Add Parameter refactoring to the methods which have been moved. We do not 
make this appear into the algorithm of Fig. [S] because we encapsulate this behavior into the Move Method operation. We 
consider Move Method is an abstract operation, which can be implemented by a refactoring tool with a single operation 
or with a composition/chain of several basic operations. We make the correspondence between abstract operation and 
tool operations in App. El (see App. IA.6|) . 

^We call business code the code that defines the operations, here the bodies of print and prettyprint, which are spread over several classes 
(by the means of overriding). 
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abstract class Graphic { 

public void p ri nt () { 

accept(new P r i n t V i s i t o r ( ) ) ; 

} 

public void p r e 1 1 y p r i n t ( ) { 

accept (new PrettyPrintVisitor ()); 

} 

public abstract void accept ( Visitor v); 

} 



class Square extends Graphic { 
int I ; 

public void accept ( V i s i to r v) { 
v.visit(this); 

} 

} 



class Ellipse extends Graphic{ 
int II , 12 ; 

public void accept ( V i s i to r v) { 
v.visit(this); 

} 

} 



Figure 3: Program with Visitor (classic class hierarchy) 



public abstract class Visitor { 

public abstract void visit(Square square); 

public abstract void visit(Ellipse ellipse); 

} 



public class PrintVisitor extends Visitor { 
public void visit(Square square) { 

System .out.print("Square(" + square.! + ")"); 

} 

public void v i s i t ( E 1 1 i ps e ellipse) { 

System . out. print(" Ellipse: (" + ellipse. II +"," + ellipse. 12 + ")"); 

} 

} 



public class PrettyPrintVisitor extends Visitor { 
public void visit(Square s){ 
System .out. print("Square." ); 

} 

public void v i s i t ( E 1 1 i p s e e){ 
System .out. print(" Ellipse ." ); 

} 

} 



Figure 4: Program with Visitor (classic class hierarchy - visitor part) 
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1. 


ForAII (m,param) in LM, c in LC do 




Let visitorname = V{m) in 




Add Para meterWithDelegate(c,m, para m.visitorna me) 




IVlovelVlethod(c, m, param+visitorname, visitorname) 




RenameMethod(visitorname, m,param+c, "visit") 




done 


2. 


ExtractSuperClass(LV, "Visitor") // with visit abstract methods 


3. 


ForAII c in LC do 




ExtractGeneralMethod(c, LM, "accept", "Visitor") 


4. 


PullUpAbstractfLC, "accept", "Visitor", S) 


5. 


ForAII m in LM do 




PullUpConcrete(LC, m, S) 



Figure 5: Simple Class Hierarchy Visitor transformation (adapted to IntelliJ idea) 

ExtractSuperClass. Introducing a new superclass and pulling up methods (steps[2]and[3]of Fig.[2]) is known as Extract 
Superclass in Fowler |Fow99) . That composite operations is also available in IntelliJ idea and Eclipse. For that reason, 
we use it in Fig. [S] (step [5]). 

However, in IntelliJ idea, we have had to provide an extension of that operation that applies to several classes 
simuleanousljH (it was already possible in Eclipse). 

Extract Method Accept. In the following code (from Square or Ellipse), the instruction o.visit(this) occurs twice 
(with a different object o). 

public void print () { 

new PrintVisitorO . visit(this) ; 

} 

public void prettyprint () { 

new PrettyPrintVisitor .visit(this) ; 

} 

That instruction has to be extracted into a method accept with o as a parameter, and the occurrences of that expression 
will be replaced by accept(o). 

The tool IntelliJ IDEA will accept to extract a same method for the two instances only after we introduce a same 
type for the receiver objects. In practice, we first introduce a new local variable for new PrintVisitor() (resp. new 
Pretty PrintVisitorO), then change the type of that variable form PrintVisitor (resp. PrettyPrintVisitor) to Visitor, 
and then the extraction of the method successes (the two instances are replaced by invocations of that method). The 
operations used in IntelliJ idea are Introduce Variable and Type Migration (as many other refactoring operations Type 
Migration checks that the change is type safe). One would may also find useful to rename the local variables or the 
parameter of accept to v or visitor (operation Rename). 

The local variables can be inlined afterward (operation Inline). 

Note that the task of making accept act on Visitors is left implied in the guidelines of Mens and Tourwe (Fig [5]). This 
task is not explained either by Fowler {Extract Method |Fow99j ). 

Again, we encapsulate these elementary changes in the ExtractGeneralMethod refactoring operation, defined in App. lA.27l 

Pull Up. Note that when accept is pulled up (step |4] of Fig. [5]), IntelliJ idea does not add the ©Override annotation 
to all the subclasses, but only in the one the operation is called on. 

Also, when print and prettyprint are pulled up (step [5] of Fig. [5]), the tool cannot take several classes simultaneously 
into account, so that the pull up does not verifies that the code are the same in all the concrete classes (in fact they 
are) . Note that for Pull Up, Eclipse can take several classes into account (it allows to remove overriding methods in these 
classes) but it does not checks that the behavior is preserved by this change. 

^ Pull up method refactoring extension plugin: |http : //plugins . intelllj ■ net/plugin/?ldea_ce&ld=6889 1 
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Visibility. In the example program, instance variables are public (package). If they were private or protected, we 
would have had to make them public so that the moved methods can access them. This does not depend on the way we 
implement the transformation, but rather to the nature of the Visitor pattern. Note that Eclipse Move makes the change 
automatically while with IntelliJ idea you have to do it after or before the Move. 

Conclusion. We have seen that as soon as we consider a refactoring tool, 

1. the guidelines have to be adapted and 

2. an algorithm can be defined (and automated). 

We have seen also that some steps are implied in the guidelines, and that, on the opposite, some chains of operations 
of the guidelines can be done with a single tool's operation. 

Finally, we have seen that we also have to adapt the chain of operation to characteristics of the initial program. In 
the following, after having studied a reverse transformation to get the program back to its initial structure, we will see 
how the algorithm is adapted to variations in the initial program. 

3 CompositeoVisitor Transformation Scheme 

We now consider an instance of the Composite pattern as the initial program (Fig. The difference between the classic 
object structure considered before and the Composite structure is recursion: the data type is recursive (subclasses make 
references to the superclass) and the operations are recursive (to traverse trees of that datatype which depth in unknown). 

In this section, all the business methods we handle take no parameter and do not return any result, and the traversal 
process is stateless. These constraints are relaxed in Sec. HI 

We also consider that the visitor classes are not part of the project in the Composite state (unlike in previous section). 

3.1 Composite— 7- Visitor Transformation 

Let us consider this part in the code of the CompositeGraphic class: 

public void print () { 

System. out .print ("Composite : " + this + " with: ("); 
for (Graphic graphic : childGraphics) { 
graphic .print () ; 

> 

System, out .printlnC) ") ; 

} 

If we apply the previous transformation algorithm (Fig. [5]), after the operation AddParameterWithDelegate (step[T]), 
we get the following (with IntelliJ idea): 

public void print () { 

print(new PrintVisitor () ) ; 

> 

public void print (PrintVisitor v) { 

System. out .print ("Composite : " + this + " with: ("); 
for (Graphic graphic : childGraphics) { 
graphic .print () ; 

> 

System, out .printlnC) ") ; 

} 

We observe that the recursive invocation to graphic.print() in the for loop has been left unchanged. The code is still 
functionally correct, but it is problematic for the following reason: if we look at the definition of Graphic. print () (in the 
program at that moment of the transformation, you cannot tell which instance of print() will be invoked because print() 
is abstract in the class Graphic, but we know that printf), as a delegator, will be pulled up to the class Graphic), we can 
see that each invocation of print() will result in the construction of a new PrintVisitor object. 

Here, if possible, one would choose to use a single PrintVisitor object instead of creating useless new ones. In fact, 
there is a means to do this with the IntelliJ idea refactorer, but, in order to do that, the print() delegator method must 
be pulled upH which impacts the rest of the algorithm (for instance, the pull-up of step [T] is already done). 

•^The trick is to first introduce an indirection (directly in the superclass), then inline the delegator invocation inside the loop, then add the 
parameter to the delegate, so that the tool is able to insert as new parameter in invocations existing objects instead of using a default value. 
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abstract class G 


ra p h i c { 




abstract 


public void 


print (); 


abstract 


public void 


prettyprint (); 


} 







class Ellipse extends Graphic{ 

public void print() { 
System . out . p r i n 1 1 n (" E 1 1 i p se :" + this); 

} 

public void p retty p r i n t ( ) { 
System . out. println(" Ellipse corresponding to the object " + this +"." 

} 

} 



class CompositeGraphic extends Graphic { 

private A r ray Li st <G ra phic> mChildGraphics = new Array List <G ra ph ic >() ; 

public void p ri nt () { 

System . out . printin (" Composite :" ) ; 
for (Graphic graphic mChildGraphics) { 
graphic . print (); 

} 

} 

public void p re tty p r i n t ( ) { 

System . out . p r i n 1 1 n (" Com posite " + this + " composed of:"); 
for (Graphic graphic mChildGraphics) { 
graphic . prettyprint (); 

} 

System . out . p r i n 1 1 n ("( end of composite)"); 

} 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra ph ic graphic) { 
mChildGraphics . remove (graphic ); 

} 



Figure 6: Base Program (class hierarchy) 
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1 



ForAII m in M do CreateEmptyClass(F(m)) 



2 



ForAII m in M do 
CreatelndirectionlnSuperClass(S,m, aux{m)) 



3 



ForAII m in M, c in C do 
lnlineMethodlnvocations(c, m, aux{m)) 



4 



ForAII m in M do 
AddParameterWithReuse(S, aux{m), V{m)) 



5 



ForAII m in M, c in C do 

MoveMethodWithDelegate(c, aux{rr\), V{rr\) 
"visit" ) 



6 



ExtractSuperClass(V, " Visitor" ) 



7 



ForAII m in M do 
GeneraliseParameter(S, aux{m), V{m), "Visitor") 



8 



MergeDuplicateMethods(S,{ aux{m) ImgM' "sccept") 



Figure 7: Base Composites- Visitor transformation 



This shows that, as soon as we rely on a refactoring tool, the chain of rcfactoring operations depends on the charac- 
teristics of the tool. 

For this reason, here we cannot encapsulate the small change in the transformation into a variation of one of the steps 
of the algorithm, but we have to adapt the whole algorithm. Our algorithm for basic Composites- Transformation is given 
in Fig. [3 

In Fig. [71 to generate temporary names, we consider a hmction aux that takes a method name and returns a method 
name. Here, aux(print) =printAux and aMa;( pretty print) = pretty printAux|f| 

Note that two bugs were encountered with IntelliJ idea at the beginning of our work, but were solved by JetBrains, 
so that no manual intervention is needed now. 

The result of this transformation is given in Figs. [5] and [HI 

3.2 Visitor— 7-Composite Transformation 

Composite— > Visitor transformation is based on moving business code from the data-type class hierarchy to the visitor 
classes. Now we do the opposite (move business code from visitor classes to composite classes). We proceed with three 
coarse steps (FigfTU]): 

i. Replace dynamic dispatch with static dispatch. 

ii. In-line the business code from the visitor structure to the composite structure. 

iii. Make some small changes to get the initial Composite pattern structure back. 

Remove Dynamic Dispatch (Fig. I10|, steps [T] and [2]) . We replace the accept (Visitor) method by some overloaded 
methods accept, one for each subtype of Visitor. This removes all dynamic dispatch in visit method invocations, so that 
their invocations can be inlined afterward. The visit methods can also be removed from the Visitor class (but not from 
the concrete visitor classes before they are inlined). 
The result of this is given in Figs. [TT] and[T^ 

Move Business Code (Fig. IIOL step [3]). The business code in the visitor classes is inlined: invocations of the visit 
methods in the composite classes are replaced by the corresponding body (the business code) and the visit methods are 
deleted. 

The result of this step is given in Fig. [13] (visitor classes are empty) . 

*Of course, we should ensure that these names are not clashing with other names in the project. 
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abstract class Graphic { 

public void pri nt () { 

accept(new P r i n t V i s i to r ( ) ) ; 

} 

public void p r e 1 1 y p r i n t ( ) { 

accept (new PrettyPrintVisitor ()); 

} 

public abstract void accept ( V 1 s i to r v); 



class Ellipse extends Graphic{ 

public void accept ( V i s i t o r v) { 
v.visit(this); 

} 

} 



class CompositeGraphic extends Graphic { 

Array List <Graphic> mChildGraphics = new ArrayList <Graphic >(); 

public void acce pt ( V i s 1 1 o r v) { 
v.vislt(this); 

} 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra ph i c graphic) { 
mChildGraphics.remove(graphic ); 

} 



Figure 8: Program with Visitor (data classes) 
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public abstract class Visitor { 

public abstract void v i s i t ( E I I i p s e ellipse); 

public abstract void v i s i t ( CompositeGraphic com posi teG ra ph ic 

} 



public class PrintVisitor extends Visitor { 

public void v i s i t ( Com positeGraph ic CompositeGraphic) { 
System . out . printin (" Composite :" ); 
for (Graphic graphic com positeGra ph ic . m Ch i Id Gra ph ics ) { 
graphic . accept(this ); 

} 

} 



public void v i s i t ( E 1 1 i p se ellipse) { 
System . out . p r i n 1 1 n (" E 1 1 i p se 



ipse 



public class P r etty P r i n t V i s i to r extends Visitor { 

public void v i s i t ( Com positeG ra ph ic CompositeGraphic) { 

Sy stem. out. println(" Composite " + CompositeGraphic +" composed of:"); 
for (Graphic graphic CO m posi teG ra ph ic . m C h i Id G ra p h i cs ) { 
graphic .accept(this); 

} 

System . out . p r i n 1 1 n ("( end of composite)"); 

} 

public void visit(Ellipse ellipse) { 

System . out . p r i n 1 1 n (" E 1 1 i p se corresponding to the object " + ellipse + 

} 



Figure 9: Program with Visitor (visitor classes) 



1. ForAII V in V do 

addSpecializedMethodlnHierarchy(S," accept" ."Visitor" ,v) 
deletelVlethodlnHierarchy(S, accept," Visitor") 

2. ForAII c in C do pushDownAII(" Visitor" /'visit" ,c) 

3. ForAII V in V, c in C do lnlineMethod(v," visit" ,c) 

4. ForAII m in M do 

renameMethod(S, accept, y(m),aux(m)) 

5. ForAII m in M do removeParameter(S,aua;(m),F(m)) 

6. ForAII m in M do replaceMethodDuplication(S,m) 

7. ForAII m in M do pushDownlmplementation(S,m) 

8. ForAII m in M do pushDownAII(S,aMa;(m)) 

9. ForAII m in M, c in C do inlineMethod(c,aitx(m)) 

10. ForAII V in V do deleteClass(v) 

11. deleteClass(" Visitor" ) 



Figure 10: Base Visitor Composite transformation 
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abstract class Graphic { 

public void print() { 

accept(new P r 1 n t V 1 s i t o r ( ) ) ; 

} 

public void p retty p r i n t ( ) { 

accept (new PrettyPrintVisitor ()); 

} 

public abstract void accept ( P r i n tV i si to r v); 
public abstract void accept ( P retty P r i n tV i s i to r v); 



class Ellipse extends Graphic{ 

public void accept ( P re tty P ri n tVi s it o r v) { 
V. visit (this ); 

} 

public void accept ( P r i n tV i s i to r v) { 
V. visit (this ); 

} 

} 



class CompositeGraphic extends Graphic { 

Array List <Graphic> mChildGraphics = new Array List <Gra ph ic >() ; 

public void accept ( P retty P ri ntVi s it o r v) { 
v. visit (this ); 

} 

public void accept ( P r 1 n t V 1 s i to r v) { 
v. visit (this ); 

} 

public void add(Graphic graphic) { 
mChildGraphics. add(graphic ); 

} 

public void remove ( G ra ph ic graphic) { 
mChildGraphics.remove(graphic ); 

} 

} 



Figure 11: Reverse-State 1 (data classes) 
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public abstract class Visitor { 
} 



public 


class PrintVisitor extends Visitor { 






public void v i s i t ( Com positeG ra phi ic co 


mpositeGraphic) { 




System . out . printin (" Composite 


" ) ; 




for (Grapiiic grapiiic compositeG 


raphic . mChildGraphicsJ { 




graptnic .accept(this); 






} 






} 






public void v i s i t ( E 1 1 i p s e ellipse) { 






System.out.println(" Ellipse 


+ ellipse); 




} 




} 







public class P r e 1 1 y P r i n t V i s i t o r extends Visitor { 

public void v i s i t ( Com positeG ra phi ic co m pos i t e G r a p ii i c ) { 

Sy St em. out. println(" Composite " + compositeGrapiiic +" composed of:"); 
for (Grapiiic grapiiic co m pos i t e G r a p ii i c . m C ii i I d G ra p hi i cs ) { 
grapiiic .accept(this); 

} 

System.out.println("(end of composite)"); 



public void v i s i t ( E 1 1 i p s e ellipse) { 

System.out.println(" Ellipse corresponding to the object " + ellipse +"."); 

} 

} 



Figure 12: Reverse-State 1 (visitor classes) 



Remove Visitors and Recover Initial Structure (Fig. I10|, steps [4l to llip . Once the business code has been 
moved into the convenient classes, the rest of the refactoring operations are common refactoring operations allowing to 
recover the composite structure (the important part is done before). 
The result of this step is given in Fig. [TH 

3.3 Result after Round Trip Transformation 

After this transformation, the program conforms to the Composite pattern (Fig. [H)) . 

A few more refactorings are necessary to recover exactly the original program: make private the fields that were made 
public during the Composite— Transformation, reorder method definitions. 

Note also that some comments are altered or lost during the transformation (which is not shown by our example). 
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abstract class Graphic { 

public «oid print() { 

accept(new P r i n t V i s i to r ( ) ) ; 

} 

public void p r e 1 1 y p r i n t ( ) { 

accept (new PrettyPrintVisitor ()); 

} 

public abstract void a ccept ( P r i n t V i s i t o r v); 
public abstract void accept ( P retty P r i n tV i s i to r v); 



class Ellipse extends Graphic{ 






public void accept ( P re tty P ri n tV i s i to r v) { 

System . out . p ri n 1 1 n (" E 1 1 i ps e corresponding to the object 


' + this + " . " 


); } 


public void accept ( P r i n t V i s i t o r v) { 

System . out . p ri n 1 1 n (" E 1 i i ps e ;" + this); 

} 

} 











class CompositeGraphic extends Graphic { 

Array List <Graphic> mChildGraphics = new ArrayList <Graphic >(); 

public void accept ( P re tty P ri n t Vis it o r v) { 

System . out. println(" Composite " + this +" composed of : " ) ; 
for (Graphic graphic mChildGraphics) { 
graphic . accept ( v ) ; 

} 

System . out . p ri n 1 1 n ("( end of composite)"); 

} 

public void acce pt ( P r i n t V i s i t o r v) { 
System .out . printin (" Composite :" ); 
for (Graphic graphic mChildGraphics) { 
graphic . accept ( v ) ; 

} 

} 

public void add(Graphic graphic) { 
mChildGraphics. add(graphic ); 

} 

public void remove ( G raph ic graphic) { 
mChildGraphics.remove(graphic ); 

} 

} 



Figure 13: Reverse-State 2 (data classes) 
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abstract class Graphic { 

public abstract void print(); 
public abstract void p r etty p r i n t ( ) ; 

} 



class Ellipse extends Graphic{ 






public void print() { 






System .out. println(" Ellipse 


: " + this ) ; 




} 






public void p rett y p r i n t () { 






System .out. println(" Ellipse 


corresponding to the object " 


+ this + " ." ); 


} 






} 







class Com posi teG ra p h i c extends Graphic { 

Array List <Graphic> m Ch i Id G ra ph ics = new Array List <Graphic >(); 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra ph ic graphic) { 
mChildGraphics.remove(graphic ); 

} 

public void print() { 

System . out . printin (" Composite :" ); 
for (Graphic graphic m C h i I d G ra ph ics ) { 
graphic . print (); 

} 

} 

public void p rett y p r i n t ( ) { 

System . out . p ri n 1 1 n (" Composite " + this + " composed of:"); 
for (Graphic graphic m C h i IdG ra ph ics ) { 
graphic . prettyprint (); 

} 

System . out . p ri n 1 1 n ("( end of composite)"); 

} 



Figure 14: Result after Back Transformations 
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4 Variants of Transformations for Various Pattern Instances 

In this section we consider some variants of either Composite pattern or Visitor pattern and we adapt the algorithm of 
transformation. 

4.1 Methods with Parameters 

In this section we consider that methods of interest have parameters. We consider a method setColor with an integer as 
parameter in the Composite hierarchy (see Fig. fT5|). 



abstract 


class Graphic 


{ 


public 


abstract void 


p ri n t ( ) ; 


public 


abstract void 


setColor(int c); 


} 







class Ellipse extends Graphlc{ 




protected int color ; 




public void print() { 
System.out.println(" Ellipse with color:" 

} 


+ color); 


public void setColor(int c){ 
this. color = c; 

} 

} 





class Co m posi teG ra p h i c extends Graphic{ 

private A r ra y L i st <G ra ph ic> m C h i I d G r a p h i cs — new A r r a y L i s t <G ra p h i c > ( ) ; 

public void print() { 

System . out . printin (" Composite :" ); 
for (Graphic graphic m C h i I d G ra p h i cs ) { 
graphic . print (); 

} 

} 

public void setColor(int c){ 

for (Graphic graphic m C h i I d G ra p h i cs ) { 
graphic . setColor(c); 

} 

} 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra p h i c graphic) { 
mChildGraphics. re move( graphic ); 

} 

} 



Figure 15: Composite with methods having parameters. 



4.1.1 Composite— !- Visitor Transformation 

At the step H] of the Composites- Visitor algorithm of Fig. [3 replace the application of the operation addParameter- 
WithReuse with parameters by the operation Introduce Parameter Object. This operation is offered by refactoring tools 
(Eclipse and IntelliJ idea). If we consider a method m(A a, B b, C c), it replaces the parameters by an object of a new 
class P it creates and which contains instances variables a, b and c. Invocations m(a,b,c) are replaced by m(new P(a,b,c)). 
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abstract class Graphic { 

public woid print(){ 

accept (new PrintVisitor()); 

} 

public void setColor(int c) { 

accept(new S e t C o I o r V i s i t o r ( c ) ) ; 

} 

public abstract void a ccept ( V i s i t o r v); 

} 



class Ellipse extends Graphic { 
protected int color ; 
void a cce pt ( V i s i t o r v) { 
v.visit(this); } 

} 



class Com posi teG ra p h i c extends Graphicj 
A r r a y L i St <G ra p h i c > m C h i I d G ra p h i cs — 

new A r r a y L i s t <G ra ph ic > { ) ; 
public void a ccept ( V i s i t o r v){ 
V. visit(this); 

} 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra ph ic graphic) { 
mChildGraphics . remove(graphic ); 

} 

A r r a y L i st <G ra p h i c> get m C h i I d G r a p h i cs ( ) { 
return mChildGraphics; 

} 

} 



Figure 16: Visitor with methods having parameters (data classes) 



4.1.2 Visitor Program 

The result program is shown by the figures [12] and 1171 

4.1.3 Visitors-Composite Transformation 

After performing the step [S] of the basic algorithm (Fig. [TU)) perform the following tasks : 

1. Delete the superclass Visitor structure. 

2. InlineClass(v) (for each visitor class v that corresponds to the business method with parameter). 

After having performed the rest of the transformation of Fig. [TOl we get the following code in the Ellipse class: 

public void setColor(int c) { 
final int cl — c; 
color — new Object () { 

private final int c = cl ; 

public int getC ( ) { 
return c ; 

} 

} getC (); 

} 

Here, we have to replace new Object(){...cl...}.getC() by cl. The reason is that we have replaced a parameter by an 
object containing the parameter with Add Object Parameter during the Composite— > Transformation, and now we have 
to do the inverse, extract a component from an object. The same has to be done in CompositeGraphic. At the moment, 
we do this manually. 

4.2 Methods Returning Values 

In this section we consider that methods of interest return results, for instance we consider a method perimeter that 
returns an Integer and toString that returns a String (see Fig. llSp. 
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public class PrintVisitor extends Visitor { 

public void v i s i t ( CompositeGraphic co m pos i t e G r a p h i c ) { 
System .out . printin (" Composite :" ); 

for (Graptnic graptnic co m posi t e G r a p in i c . m C in i I d G r a p ii i cs ) { 
graphic .accept(this ); 

} } 

public void v i s i t ( E 1 1 i p s e ellipse) { 

System.out.println(" Ellipse with color: "+ ellipse, color); } 

} 



public class S et C o I o r V i s i t o r extends Visitorj 
private final int c; 
public S e t C o I o r V i s i t o r ( i n t c) { 

this . c = c ; } 
public int getC ( ) { 

return c; } 
public void v i s i t ( CompositeGraphic CompositeGraphic) { 

for (Graphic graphic co m posi t eG r a p h i c . m C h i I d G r a p h i cs ) { 
graphic .accept(this ); 

} } 

public void v i s i t ( E 1 1 i p s e ellipse) { 
ellipse, color — getC(); 

} 

} 



Figure 17: Visitor with methods having parameters (visitor classes) 

This would require to have one accept method for each return type. To avoid this, we use generic types (see the visitor 
structure in Figs. fT^ and . Note that the use of Java generic types is only possible with object types (such as Integer), 
not with raw types (such as int). 

4.2.1 Composite-^ Visitor Transformation 

In the stepiniof the base algorithm of Fig. [71 we use the operation ExtractSuperClassWithoutPullUp (see App. IA.9.1[) and 
then the operation PullUpWithGenerics (see App. ETTH)) . The last operation is used to pull up methods having different 
return types and create the right generic types. 

4.2.2 Visitor Program 

The result program is shown by the figures [19] and [20l 

4.2.3 Visitor— ;>Composite Transformation 

At the step [T] of the base algorithm of the Fig. [TUl we must specify the return type of each accept method and replace the 
parameter type by the corresponding type (the operation addSpecializedMethodlnHierarchy must change the return type 
in addition to the parameter type). 

4.3 Interface instead of Abstract class in the Composite structure 

In this section we consider that the top of the Composite hierarchy in an interface instead of abstract class (see Fig. I^T]) . 
As we have to put some code in the superclass, we just introduce an abstract class in the hierarchy. 

4.3.1 Composite^> Visitor Transformation 

Before performing the base algorithm of Fig. [3 create an abstract class that implements the interface of the Composite 
hierarchy. This is done as the following : 

1. Extract a super-Class from composite classes. 

2. Pull up the business methods as abstract methods to the super-Class. 

3. Make the super-class implementing the interface of the Composite structure. 

4. Change any use of type Interface to type super-Class (use Type Migration in IntelliJ idea to perform this operation). 

5. Push down business method from the interface of composite structure (this will help to avoid any confusion or 
complexity of manipulating business methods in the abstract class). 
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abstract class Graphicj 

public abstract Integer perimeter (); 
public abstract String toString (); 

} 



class Ellipse extends Graphic{ 
int perimeter; 

public Ellipse (int perimeter){ 
this . perimeter = perimeter ;}; 

public Integer perimeter () { 
return ( perimeter ) ; 

} 

public String toString () { 

return ("Ellipse : " + I ntege r . toSt ri ng ( peri meter )) ; 

} 

} 



class Com positeG ra ph ic extends Graphic { 




private A r ra y L i st <G ra ph ic> m C h i 1 d G ra p h i cs 


= new A r ra y L i St <G ra ph ic > ; 


public Integer perimeter() { 
int acc = ; 

for (Graphic graphic m C h i Id G ra ph i cs 
acc += gra ph ic . peri m eter ( ) ; 

} 

return acc ; 

} 


{ 


public String toString(){ 
String s ; 

s = new String ("Composite with: "); 
for (Graphic graphic m C h i IdG ra ph ics 
s = s . concat ( gra ph ic . toSt r i ng ( ) + 

} 

System . out . printin (" (end)" ); 
return s ; 

} 


{ 

" , " ) ; 


public void add(Graphic graphic) { 
mChildGraphics.add(graphic); 

} 




public void remove ( G ra p h i c graphic) { 
mChildGraphics . remove(graphic ); 

} 

} 





Figure 18: Composite with methods returning types 
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abstract class Graphic{ 

public Integer perimeter() { 

return accept{new P e r i m et e r V i si t o r ( ) ) ; 

} 

public String toStrlng() { 

return accept(new ToStri ngVisitor ( ) ) ; 

} 

public abstract <T> T accept ( Visitor <T> v); 



class Ellipse extends Graphic{ 
int peri meter ; 

public Ellipse (int perimeter){ 
this . perimeter = perimeter ;}; 

public <T> T accept ( V Is i to r <T> v) { 
return v.visit(this); 

} 

} 



class ComposlteGraphic extends Graphic { 
A r ra y L I St <G ra ph ic > mChildGraphics = 

new A r r a y L I s t <G ra ph ic > ( ) ; 
public void add(Graphlc graphic) { 
mChildGraphics.add(graphlc ); 

} 

public void remove ( G ra p h I c graphic) { 
mChildGraphics . remove(graphic ); 

} 

Array List <Graphic> get m Ch I Id G ra ph Ics () { 
return mChildGraphics; 

} 

public <T> T accept { Visitor <T> v) { 
return v.visit(this); 

} 

} 



Figure 19: Visitor with generics (data classes) 



public class Tot a I P e r I m ete r VI s 1 1 o r extends Visitor <lnteger>{ 
public Integer v i s i t ( Com poslteG ra ph ic compositeGraphic ) { 
int acc = ; 

for (Graphic graphic com poslteG ra ph ic . mCh i IdG ra ph ics ) { 
acc += gra ph I c . accept ( t h i s ) ; 

} 

return acc ; 

} 

public Integer v i s i t ( E 1 1 i pse ellipse) { 
return ( e I I i ps e . peri meter ) ; 

} 

} 



public class ToS t r i ngV isi to r extends Visitor <String> { 
public String v i s i t ( Com positeGra ph ic compositeGraphic) { 
String s ; 

s = new String ("Composite with: "); 

for (Graphic graphic com poslteG ra p h I c . m C h i Id G ra ph ics ) { 
s = s.concat(graphlc.accept(this) + ", "); 

} 

System . out . printin (" (end)" ); 
return s ; 

} 

public String v I s 1 1 ( E 1 1 1 p s e ellipse) { 
return ("Ellipse " + 1 n t ege r . toS t r i n g ( e I I I p s e . per I meter ) ) ; 

} 



Figure 20: Visitor with generics (visitor classes) 
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inter fa ce Graphic { 




abstract public void 


pri n t ( ) ; 


abstract public void 


prettyprint (); 


} 





class Ellipse implements Graphic{ 
public void print() { 

System . out. println(" Ellipse :" + this); 

} 

public void p ratty p r i n t () { 

System . out. println(" Ellipse corresponding to the object " + this +"."); 

} 

} 



class Com posi teG ra p h i c implements Graphic { 

private A r ra y L i st <G ra ph ic> m C h i I d G ra ph ics = new Array List <Gra ph ic >() ; 
public void print() { 

System .out . printin ("Composite :" ); 
for (Graphic graphic m C h i IdG ra ph ics ) { 
graphic . print (); 

} 

} 

public void p rett y p r i n t ( ) { 

System . out. println(" Composite " + this +" com posed of : " ) ; 
for (Graphic graphic m C h i I d G ra ph ics ) { 

graphic . prettyprint (); 

} 

System. out. printin ("(end of composite)"); 

} 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra ph i c graphic) { 
mChildGraphics.remove(graphic ); 

} 

} 



Figure 21: Composite with Interface 
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interface Graphic { 
void print (); 
void p r e 1 1 y p r i n t ( ) ; 

} 



public abstract class Abst ractCom posi te implements Graphic { 
public void print() { 

accept(new P r i n t V i s i t o r ( ) ) ; 

} 

public void p re 1 1 y p r i n t ( ) { 

accept ( new PrettyPrintVisitor ()); 

} 

public abstract void a ccept ( V i s i t o r v); 

} 



class Ellipse extends AbstractCom posite implements Graphic{ 
public void accept ( V i s i to r v){ 
V. visit(this); 

} 

} 



class Com posi teG ra p h i c extends A bst ra ct Com posi te implements Graphic { 

A r r a y L i st <A bst ra ct Co m posi te > m C h i I d G r a p h i cs = new A r ra y L i st <Abst ra ct Co m posi te >(); 
public void accept ( V i s i t o r v){ 
V. visit(this); 

} 

public void add ( A bst ra ct Com posi te graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( AbstractCom posite graphic) { 
mChildGraphics . remove(graphic ); 

} 

A r r a y L i st < A bst ra ct Co m posi te > get m C h i I d G ra p h i cs ( ) { 
return mChildGraphics; 

} 

} 



Figure 22: Visitor structure for Interface instead of Abstract Composite (data classes) 



After doing the previous tasks, perform the base algorithm to reach the Visitor structure. 

4.3.2 Visitor Program 

The result program is shown by the figures [22] and [23l 

4.3.3 Visitor— ^Composite Transformation 

After performing the basic algorithm of back transformation (Fig. [TU|) . change any use of the super-class type to the 
interface type {Type Migration in IntelliJ idea). Finally, delete the intermediate super-class. 

4.4 Class Hierarchies with Several Levels 

In this section we consider that the Composite class hierarchy has several levels (we add a subclass ColoredEllipse to 
Ellipse^ which provides an overriding method for only one of the two business methods, see Fig. I24p . The interest of this 
variant is that a subclass extends a composite and does not redefine all business methods. This subclass exists in different 
depth of hierarchy as the main composite class. 

4.4.1 Composite-^ Visitor Transformation 

Before performing the base algorithm of Fig. [71 apply the operation pushDownNotRedefinedMethod (see App. IA.24P in 
order to push down the methods that exists in the composites but not redefined in the sub-classes. After that, the basic 
algorithm applies. 
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public class PrintVisitor extends Visitor{ 

public void v 1 s i t ( Com posi teG ra ph ic co m pos i t e G r a p h i c ) { 
System .out . printin (" Composite :" ); 

for ( A bst ra ct Co m pos i t e graphic co m posi te G ra p in i c . m C h i I d G ra p h i cs ) { 
grapiiic.accept(this ); 

} 

} 

public void v i s i t ( E 1 1 i p s e ellipse) { 

System.out.println(" Ellipse :" + ellipse); 

} 

} 



public class P r e 1 1 y P r i n t V i s i t o r extends Visitor { 

public void v i s i t ( Com posi teG ra p h ic co m pos i t e G r a p h i c ) { 

System. out. printin ("Composite " + compositeGraphic +" composed of:"); 
for ( A bst r a ct Co m pos i t e graphic co m posi te G ra p h i c . m C h i I d G ra p h i cs ) { 
graphic . accept(this ); 

} 

System. out. printin ("(end of composite)"); 



public void v i s i t ( E 1 1 i p s e ellipse) { 

System.out.println(" Ellipse corresponding to the object " + ellipse +"."); 

} 

} 



Figure 23: Visitor structure for Interface instead of Abstract Composite (visitor classes) 



4.4.2 Visitor Program 

The result program is shown by the figures [25] and 1261 

4.4.3 Visitors-Composite Transformation 

At the step [H] of the basic algorithm (see Fig. 1101) use the operation pushDownNotRedefinedMethod in order to push down 
the auxiliary methods that exist in composites and are not redefined in their sub-classes. 



23 



abstract class G 


raphic { 




abstract 


public void 


print (); 


abstract 


public void 


prettyprint (); 


} 







class Ellipse extends Graphic{ 

public void pri nt () { 

System . out . p r i n 1 1 n ( " E II i pse :" + this); 

} 

public void p re 1 1 y p r i n t ( ) { 

System . out. println(" Ellipse corresponding to the object " + this +"."); 

} 

} 



class Co 1 o r ed E 1 1 1 pse extends Ellipse{ 




1 n t color; 




public void print() { 




System . out . p ri n 1 1 n (" E 1 1 i ps e :" 


+ color); 


} 




} 





class Com posi t eG ra p h i c extends Graphic { 
private A r ray Li st <G ra phic> m C h lid G ra p h i cs = 
public void print() { 

System . out . printin (" Composite :" ) ; 
for (Graphic graphic m C h i Id G ra ph ics ) { 
graphic . print (); 

} 

} 

public void p r e 1 1 y p r i n t () { 
System.out.println("Composite " + this +" 
for (Graphic graphic mChildGraphics) { 
graphic . prettyprint (); 

} 

System . out . p r i n 1 1 n ("( end of composite)"); 

} 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra ph ic graphic) { 
mChildGraphics . remove(graphic ); 

} 

} 



Figure 24: Composite with multiple hierarchical levels. 



new ArrayList <Graphic >(); 



composed of : " ) ; 
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abstract class Graphic { 
public void print() { 

accept(new P r i n t V i s i t o r ( ) ) ; 

} 

public void p re 1 1 y p r i n t ( ) { 

accept (new PrettyPrintVisitor ()); 

} 

public abstract void accept ( Visitor v); 

} 



class Ellipse extends Graphic{ 

public void accept ( Visitor v) { 
V. visit (this ); 

} 

} 



class C o I o r ed E 1 1 i pse extends Eliipse{ 
i n t color; 

public void accept ( Visitor v) { 
v. visit (this ); 

} 



class CompositeGraphic extends Graphic { 

Array List <Graphic> mChildGraphics = new ArrayList <Graphic >(); 

public void add(Graphic graphic) { 
mChildGraphics.add(graphic ); 

} 

public void remove ( G ra p h i c graphic) { 
mChildGraphics . remove(graphic ); 

} 

A r ra y L i St <G ra p h i c > get m C h i I d G ra ph ics ( ) { 
return mChildGraphics; 

} 

public void accept ( Visitor v) { 
v. visit (this ); 

} 



Figure 25: Visitor with niultiple hierarchical levels (data classes) 



25 



public class PrintVisitor extends Visitor { 

public void v i s i t ( Com posi teG ra ph ic co m pos i t e G r a p h i c ) { 
System .out . printin (" Composite :" ); 

for (Graphic graptnic co m posi t eG r a p in i c . m C h i I d G r a p h i cs ) { 
graphic .accept(this ); 

} 

} 

public void v i s i t ( E 1 1 i p s e ellipse) { 

System.out.println(" Ellipse :" + ellipse); 

} 

public void v i s i t ( C o I o r ed E 1 1 i pse c o I o r e d E 1 1 i p s e ) { 

System.out.println(" Ellipse :" + coloredEllipse. color); 

} 

} 



public class P r e 1 1 y P r i n t V i s i t o r extends Visitor { 

public void v i s i t ( Com posi teG ra ph ic co m pos i t e G r a p h i c ) { 

System . out. println(" Composite " + compositeGraphic +" composed of:"); 
for (Graphic graphic co m posi t e G r a p h i c . m C h i I d G r a p h i cs ) { 
graphic .accept(this ); 

} 

System. out. printin ("(end of composite)"); 

} 

public void v i s i t ( E 1 1 i pse ellipse) { 

System.out.println(" Ellipse corresponding to the object " + ellipse +"."); 

} 

public void v i s i t ( Co I o r ed E 1 1 i pse coloredEllipse) { 

System.out.println(" Ellipse ;" + coloredEllipse. color); 

} 

} 



Figure 26: Visitor with multiple hierarchical levels (visitor classes) 

5 Application to JHotDraw 

To validate our transformation algorithms, we apply them to JHotDraw jGIj . 

To know on which classes to apply the transformation, we use a pattern detection tool. We have applied 
pattern4 |TCSH06] : it reports a Composite structure with 6 operations and it reports the superclass and the sub- 
class that implements the "container". The operations are defined by overriding methods in about 12 classes of the class 
hierarchy. 

The semi-automatic Composite— ;> Visitor transformation applies successfully with the help of variations studied in 
Sec. m (and with the limitations explained in these variations). 

It takes between 8 and 9 hours to apply the whole Composite— s> Visitor transformation interactively. Most of time is 
due to interaction (selection the entities to transform, selecting the refactoring operation and giving parameters). The 
automated version takes a few minutes. We are focusing on automating the whole reversible transformation on JhotDraw. 

A second instance of the pattern is found but we have not transformed it since it has only one operation defined. 

6 Related work 

6.1 Refactoring to Patterns 

Using chains of elementary refactoring operations to introduce design patterns into programs is not new. The idea is first 
proposed by Batory and Takuda |BT95) . 

O Cinneide |OC00j give transformation to introduce several patterns but not the Visitor (he considers in |OCOOI that 
automating the introduction of a visitor pattern is impractical). 

Kerievsky |Ker04j proposes two sets of guidelines to introduce Visitor patterns. The first one is similar to the one 
from Mens and Tourwe |MT04| described in Sec. The second one applies to an "external accumulation" : instead of 
transforming an operation defined by overriding methods in the class hierarchy, it applies to an operation defined outside of 
the class hierarchy by a switch on the type of an object with instanceof and type casts. Neither Mens and Tourwe [MT04j 
nor Kerievsky 'Ker04' give the inverse transformation. 

Hills et al. HKVDS Vllj have transformed a program based on a Visitor pattern to introduce a Visitor pattern instead 
(the Visitor pattern is similar to the Composite pattern). Their transformation is automated, with a few interactions 
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with the user. Since their transformation is dedicated to a specific program and is not abstractly described, it requires 
some work to be apphed to other programs. 

Jeaon et al. (JLB02 provide automatic inference of sequence of refactoring operations allowing to reach design pattern 
based versions of programs. Sudan et al. |PRSK10] provide an inference of a sequence of refactoring operations allowing 
to pass from a given version of a program to a second given version. Such tools could be used to infer variations of our 
transformation algorithms for variations in initial programs, or to infer transformations between other patterns. 

6.2 Building Complex Refactoring Operations 

The transformations we aim at can be seen as complex/composed refactoring operations. As each refactoring operation 
has specific preconditions, and as we use a large number of elementary transformations, assistance for building such 
transformations would be valuable. Several works provide languages to build or compose refactoring operations. O 
Cinneide and Nixon [OCNOOj show how to compose elementary refactoring operations with pre/post-conditions, as well 
as Kniesel and Koch (KK04| . 

Verbaere et al. propose a language dedicated to building refactoring operations |VEdM06] . and Klint et al. pro- 
pose a language dedicated to program manipulation [KSV09j . which they have used to build the Visitor— ^Interpreter 
transformation |HKVDSVll) . 

6.3 Design Patterns Discovery 

To provide a fully automated transformation, detection of the occurrences of the initial design pattern must be automated. 
Several work exist in that domain. Smith and Scott provide a tool that discovers variants of a design pattern in a given 
program [SS03| . Such tools can be used to automatically provide inputs to our transformations. 

On the opposite, some tools detect pattern precursors, anti-patterns or code smells |RJ04I IMGL06) . but, in our 
approach, we consider that the initial program has already a good design. 



7 Conclusion 

In this report: 

• We have shown how to use refactoring operations to transform a Java program conforming to the Composite pattern 
(or Interpreter pattern) into a program (still in Java) conforming to the Visitor pattern and vice versa. 

• We have explained how to use some refactoring tools (IntelliJ idea and Eclipse) to perform these transformations. 
We have seen that some basic refactorings are not supported by these tools. 

• We have discussed some variations in transformations to adapt to variations in the initial programs. 

This work is a first step towards automation of these transformations so that the user does not have to perform each 
basic refactoring with a refactoring tool. On the example of the JHotDraw program, automation can reduce transformation 
time from 8 hours to a few minutes. This kind of automated transformation can be used to provide different versions of 
a same programs with different properties with respect to modularity [CDA12) . 
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A Refactoring Operations 

In this appendix, we define refactoring operations we use in our transformations. For each operation, we give an example 
to explain its behavior, and we tell how it is performed with IntelliJ idea or Eclipse. We give some preconditions when 
an operation applies only in a specific case. These preconditions are neither minimal (they can be refined into weaker 
conditions) nor complete (they are sufficient in our basic examples, but not in some situations we have not considered). 
Also, some preconditions dealing with name clashes are left implied. 

The given backward descriptions are used for static composition of refactorings |KK04) (see App. IB|) . 
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A.l CreateEmptyClass 

Overview: CreateEmptyClass (classname c): this operation is used t add a new class c. 
Refactoring tools, new Class in Eclipse and IntelliJ idea. 

Precondition. 

{-iexistsType{c)) 

Backward Description. 

ExistsClass(c) T 
ExistsType(c) i-)- T 
IsAbstractClass(c) i— > _L 
ExistsMethodDef inition(c, F) i-> _L 
ExistsMethodDef initionWithParams(c, y, []) i— > _L 
ExistsMethodDefinitionWithParams(c, F, [Tl]) _L 
ExistsMethodDefinitionWithParains(c, y, [T1;T2]) i-> ± 
ExistsMethodDef initionWithParains(c,y, [T1;T2;T3]) ^ _L 
ExistsMethodDef initionWithParains(c,y, [T1;T2;T3;T4]) _L 
ExistsMethodDefinitionWithParains(c,y, [T1;T2;T3;T4;T5]) _L 
IsInheritedMethod(c, y) i->^ lsVisihle{java.lang.Object,Y,c) 

IsInheritedMethodWithParains(c, y, []) i-^ IsVisihleKethodijava.lang. Object, Y, [],c) 

IsInheritedMethodWithParams(c,y, [Tl]) ^ lsV±s±hleHethod{java.lang.Object,Y, [Tl],c) 

IsInheritedMethodWithParains(c, Y, [Tl; T2]) H> lsVisihlenethod{java.lang.Object, Y, [Tl; T2],c) 

IsInheritedMethodWithParams(c, Y, [Tl; T2; T3]) i-^ IsVisibleMethod(iat;o./an5.06ierf, Y, [Tl; T2; T3], c) 

IsInlieritedMetliodWithParams(c, Y, [Tl; T2; T3; T4]) ^ IsVisihlenethod{java.lang.Object, Y, [Tl; T2; T3; T4], c) 

IsIiilieritedMetliodWithParains(c, Y, [Tl; T2; T3; T4; T5]) iH- lsVisihlenethod{java.lang.Object, Y, [Tl; T2; T3; T4; T5], c) 

IsSubType(c, X) _L {X ^ java.lang. Object) 

ExtendsDirectly(c, X) i-^- _L {X ^ java.lang .Object) 

ExistsMethodDef initionWithParams(B, y, [c]) M- _L 

ExistsMethodDef initionWithParams(_B, y, [c; Tl]) ^ ± 

ExistsMethodDef iiiitionWithParams(i?, y, [Tl; c]) _L 

ExistsMethodDefinitionWithParams(i3,y, [Tl;T2;c]) _L 

ExistsMethodDefinitionWithParams(B,y, [Tl;c;T2]) i->- _L 

ExistsMetliodDefinitionWithParams(B, y [c;Tl;T2]) i->- _L 

IsInheritedMethodWithParams(i?, y, [c]) ± 

IsInheritedMethodWithParams(i3,y, [c;Tl]) i-^ _L 

IsInheritedMethodWithParams(B,y, [ri;c]) >->■ _L 

IsInheritedMethodWithParams(B,y, [Tl;T2;c]) ^ _L 

IsInheritedMethodWithParams(S,y, [Tl;c;T2]) H> _L 

IsInheritedMethodWithParams(B,y, [c;Tl;T2]) i-J> _L 



ExistsParameterWithNaiiie(i?, y, 


{c],P) 




_L 






ExistsParameterWithName(B, Y, 


[c;Tl] 




I-)- 


_L 




ExistsParameterWithName(i3, Y, 


Tl;c] 






± 




ExistsParajneterWithNanie(_B. Y, 


Tl:c: 


T2] 


^P) 




_L 


ExistsParameterWithName(i3, Y, 


[Tl;T2;c] 


,P) 




_L 


ExistsParameterWithNaine(B, Y, 


[c;Tl; 


T2] 


,P) 




_L 


ExistsParameterWithType(i?. Y, 


[4,P) 




± 






ExistsParajneterWithType(_B, Y, 


[c;Tl] 


,P) 




_L 




ExistsParameterWithType(i3, Y, 


[Tl;c] 


,P) 




_L 




ExistsParaineterWithType(i3, Y, 


[Tl;c; 


T2] 


,P) 


I-)- 


_L 


ExistsParaineterWithType(B, Y, 


;ri;r2;c] 


,P) 


!->• 


_L 


ExistsParaineterWithType(B, Y, 


[c;Tl; 


T2] 


,P) 


I-)- 


_L 
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IsUsedMethodIn(c,S,F) ^ ± 

IsUsedMethod(c,B, [Tl]) k> _L 
IsUsedMethod(c,S, [ri;r2]) i-> ± 
IsUsedMethod(c, B, [ri;r2;r3]) ^ ± 
IsUsedMethod(c,B, [T1;T2;T3;T4]) h->. ± 
IsUsedConstructorAsMethodParameter(c, y) i— >■ _L 
IsUsedConstructorAsInitializer(c, i?, y) ^ _L 
IsUsedConstructorAsObjectReceiver(c, -B, y) i— > _L 
IsUsedConstructorAsMethodParameter(i?, c, y) i->- _L 
IsUsedConstructorAsInitializer(B, c, y) _L 
IsUsedConstructorAsObjectReceiver(S, c, y) i->- _L 
IsSubType(S, c) _L 
ExtendsDirectly(B, c) _L 
MethodIsUsedWithType(B,y, [P], [c]) _L 
MetliodIsUsedWithType(B,y, [P], [c;ri]) ^ _L 
MethodIsUsedWithType(S,y, [P], [Tl;c]) >-> _L 
MethodIsUsedWithType(S,y, [F], [Tl;c;r2]) H- _L 
MethodIsUsedWithType(B, y, [P], [Tl; T2; c]) _L 

AllInvokedMethodsOnObj ectOInBodyOf MAreDeclaredInC(c, Tl, T2, T3) _L 

AllInvokedMethodsWithParameterOInBodyDf MAreNotOverloaded(c, Tl, T2) i-^ 

BoundVariableInMethodBody(c,Tl,T2) _L 

ExistsField(c, P) _L 

ExistsMethodInvocation(c, y, T1,X) _L 

ExistsAbstractMethod(c, y) i-> ± 

IsIndirectlyRecursive(c, y) i— _L 

IsVisibleMethod(c, y, [T1],P) H- _L 

IsVisibleMethod(c,y, [T1;T2],P) _L 

IsVisibleMethod(c,y, [T1;T2;T3],B) _L 

IsVisibleMethod(P,y, [P],c) i-> _L 

IsVisibleMethod(P,y, [P;Tl],c) i-^ _L 

IsVisibleMethod(B,y, [Tl;P],c) _L 

IsVisibleMethod(B,y, [Tl;T2;B],c) _L 

IsVisibleMethod(P,y, [Tl;P;T2],c) ^ ± 

IsVisibleMetliod(P.y [P;Tl;T2],c) H> ± 

Islnverter(c,y,ri,r2) i-^ _L 

IsDelegator(c,y,X) ± 

IsAbstractClass(c) i-> _L 

IsUsedMethodIn(c,y,P) i-> _L 

IsUsedMethodIn(P, y, c) H- _L 

IsPriinitiveType(c) i-)- _L 

IsPublic(c,y) ^ _L 

IsProtected(c, y) t-^. _L 

IsPrivate(c, y) _L 

IsUsedAttributeInMethodBody(c, X, y) _L 
IsGenericsSubtype(c, [T1],B, [T2]) i-^ _L 
IsGenericsSubtype(c, [Tl; T2], P, [T4; T3]) ± 
IsGenericsSubtype(c, [T1;T2;T3],P, [T4;T5;T6]) _L 
IsInheritedField(c, P) i-)- _L 
IsOverridden(c, y) i->^ _L 
IsOverloaded(c, y) f->- _L 
IsOverriding(c, y) h-> _L 
IsRecursiveMethod(c, y) _L 
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IsRecursiveMethod(c, y) i-> _L 

HasReturiiType(c, y, n) i~> _L 
HasParameterType(c, Tl) i— >■ _L 
HasParameterType(i3, c) i— >■ _L 
MethodHasParameterType(c, y, Tl) ± 
AllSubclasses(c, [C1;C2;C3]) ^ _L 
ExtendsT)iTectly{c,java.lang.Object) i-^ T 



A. 2 CreatelndirectionlnSuperClass 

Overview: CreatelndirectionlnSuperclass (classname s, subclasses [a,b], methodname m, types [t,t'], returntype q, newname 
n) : this operation is used to create an indirection of the method s::m to the method n in all the hierarchy. 



original code 



abstract class S { 
abstract int m( ); 

} 



class A extends S { 
int m ( ) { return 1 ; } 

} 



class B extends S { 
int m ( ) { return 2; } 

} 



refactored code 



abstract class S { 



abstract int maux(); 
int m( ) { return maux( 



class A extends S { 

int maux ( ) I { return 1 ; } 

} ' ' 



class B extends S { 
int 



} 



maux I 



{ return 2; } 



Refactoring tools. With IntclUJ idea: 

• Use Change Signature on the method m in class s (select "delegate via overloading method" , specify the new name 
n, specify the desired visibility). 

With Eclipse: 

• Use Change Method Signature on the method m in class s (specify to "keep original method as delegate to changed 
method", and specify the new name n). 



Precondition. 

(ExistsClass(s) 

A IsAbstractClass(s) 

A ExistsMethodDef initionWithParams(s, m, [t; t']) 

A ExistsAbstractMethod(s, m) 

A ^IsInheritedMethod(s, n) 

A -iIsInheritedMethodWithParams(s, n, [t; t']) 

A -lExistsMethodDef initionWithParams(s,n, [t;t']) 

A AllSubclasses(s, [a; b]) 

A HasReturnType(s, m, q) 

A -iIsPrivate(s, m) 

A -iIsPrivate(a, m) 

A -iIsPrivate(6, m) 

A ExistsMethodDef inition(s, m) 

A ExistsMethodDef inition(a, m) 

A ExistsMethodDef inition(6, m) 

A -lExistsMethodDef inition(s,n) 

A -lExistsMethodDef inition(a, n) 

A -lExistsMethodDef inition(6, n)) 
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Backward Description. 

ExistsAbstractMethod(s, n) H> T 

ExistsAbstractMethod(s, m) i— > _L 
IsDelegator(s, m, n) i->- T 

IsIiiheritedMethodWithParams(s,n, i-)- _L 

IsOverriding(,s, n) M> _L 

HasReturnType(s, n, q) i— >■ HasReturnType(,s, m, q) 
HasReturnType(a, n, q) i-^- HasReturnType(s, m, q) 
HasReturnType(6, n, g) i-)- HasReturiiType(s, m, g) 
ExistsMethodDef inition(s, n) i-t- ExistsMethodDef inition(s, m) 
ExistsMethodDef inition(a, n) h- > ExistsMethodDef iiiition(a, m) 
ExistsMethodDef inition(6, n) i— ?• ExistsMethodDef inition(6, m) 
ExistsMethodDefinitionWithParams(s,n, T 
ExistsMethodDef initionWithParams(a, n, [t; t']) i-> T 
ExistsMethodDef initionWithParams(5, n, [t; i']) i— )■ T 
ExistsMethodDef iiiitioiiWithParams(s, n, [PI]) i— > _L 
ExistsMethodDef initionWithParams(a, n, [PI]) i->- _L 
ExistsMethodDef initionWithParams(6, n, [PI]) i-> ± 
ExistsMethodDef initionWithParams(s, n, [PI; P2]) ± 
ExistsMethodDefinitionWithParams(a,n, [P1;P2]) ^ _L 
ExistsMethodDefinitionWithParams(6, n, [P1;P2]) H> _L 
ExistsMethodDef iiiitionWithParams(s,n, [PI; P2; P3]) _L 
ExistsMethodDefinitionWithParams(a,n, [P1;P2;P3]) _L 
ExistsMethodDefinitionWithParains(6,r7„ [PI; P2; P3]) ^ ± 
ExistsMethodDef initionWithParains(s, n, [PI; P2; P3; P4]) i-> _L 
ExistsMethodDefiiiitionWithParains(a,n, [P1;P2;P3;P4]) _L 
ExistsMethodDefinitionWithParams(6,n, [P1;P2;P3;P4]) i-^ _L 
ExistsParameterWithName(s, n, [i; t'], A'^) h- > _L 
ExistsParameterWithNanie(a, n, [t; i'], A^) ^ 1. 
ExistsParameterWithName(6, n, [f; i'], A'^) i— > _L 

ExistsParaineterWithNaiiie(s,n, [P1],N) ExistsParaineterWithMame(s, m, [PI], A'') 
ExistsPeiraineterWithNaiiie(a, n, [PI], A^) i— >■ ExistsParaineterWithName(a, m, [PI], A^) 
ExistsParameterWithNajne(6, n, [PI], A^) ExistsParameterWithName(6, m, [PI], A'') 
ExistsMethodDef inition(a, m) ^ _L 
ExistsMethodDef inition(&, m) i-^ _L 
ExistsMethodDef initionWithParams(a, m, [f;t']) i-> _L 
ExistsMethodDef initionWithParains(6, m, [t; t']) H> -L 
ExistsMethodDef initionWithParains(a, TO, [PI]) H> _L 
ExistsMethodDef initionWithParains(6, TO, [PI]) i-> _L 
IsIndirectlyRecursive(a, n) i->- IsRecursiveMethod(a, to) 
IsIndirectlyRecursive(6, n) i— > IsRecursiveMethod(6, to) 
ExistsMethodInvocation(a, n, s, to) ^ IsRecursiveMethod(a, m) 
ExistsMethodInvocation(&, n, s, to) h- > IsRecursiveMethod(&, to) 
BoundVariableIiiMethodBody(s, n, V) BoundVariableInMethodBody(s, m, V) 
BoundVariableInMethodBody(o, n, F) i->- BoundVariableInMethodBody(a, to, F) 
BoundVariableInMethodBody(6, n, F) i->- BoundVariableInMethodBody(6, to, F) 
IsOverloaded(s, n) _L 
IsOverloaded(a, n) _L 
IsOverloaded(6, n) i-)- _L 
IsOverridden(s, n) M> _L 
IsOverridden(a, n) i— >■ IsOverridden(a, to) 
IsOverriddeii(6, n) i— > IsOverridden(6, to) 
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IsOverriding(a, n) i-)- IsOverridiiig(a, m) 
IsOverriding(&. n) i— > IsOverriding(6, m) 
IsRecursiveMethod(s, n) i— ?■ _L 
IsRecursiveMethod(a, n) _L 
IsRecursiveMethod(6, n) _L 

AllInvokedMethodsOnObj ectOInBodyOf MAreDeclaredInC(s, n, N, V) ^ 

AllInvokedMethodsOnObjectOInBodyOf MAreDeclaredIiiC(s, m, N, V) 
AllInvokedMethodsOnObj ectOInBodyOf MAreDeclaredInC(a, n, N, V) 

AllInvokedMethodsOnObj ectOInBodyOfMAreDeclaredInC(a, m, A'', V) 
AllInvokedMethodsOnObj ectOInBodyOf MAreDeclaredInC(&, n, N, V) ^ 

AllInvokedMethodsOnObj ectOInBodyOf MAreDeclaredInC(6, m, A^, V) 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(s, n, N) 

AllInvokedMethodsWithParameterOInBodyOfMAreNotOverloaded(s, m, A'') 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(a, n, N) i->- 

AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(a, m, N) 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(6, n, N) i->- 

AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(6, m, N) 

IsPublic(s, n) h- > IsPublic(s, m) 
IsPublic(a, n) >->■ IsPublic(a, m) 
IsPublic(6, n) IsPublic(6, m) 
IsProtected(s, n) IsProtected(.s, m) 
IsProtected(a, n) H> IsProtected(a, m) 
IsProtected(6, n) i— >■ IsProtected(6, m) 
IsPrivate(s, attribuf) i->- _L 
lsPT±va.te{a, attribut) i->- _L 
lsPTiva.te{b,attribut) i— > _L 
IsPrivate(s, n) i— >■ _L 
IsPrivate(a, n) i-^ _L 
IsPrivate(6, n) i->- _L 

IsDverriding(a, n) i— >■ IsOverriding(a, m) 
IsDverriding(fe, n) H> IsDverriding(&, m) 
IsDelegator(a, n, y) i— > IsDelegator(a, m, y) 
IsDelegator(6, n, y) i->- IsDelegator(6, m, y) 
IsDelegator(a, y, n) IsDelegator(a, y, m) 
IsDelegator(6, y, n) h- > IsDelegator(6, y, m) 

IsInheritedMethodWithParains(a, n, [t;t']) i— >■ IsVisibleMethod(s, m, [t;t'],a) 
IsInheritedMethodWithParams(6, n, [t; t']) >->■ IsVisibleMethod(s, m, [t; t'],b) 
MethodIsUsedWithType(a, n, [t; t'], [t; t']) MethodIsUsedWithType(a, m, [t; t'], [t; t']) 
MethodIsUsedWithType(6, n, [t;t'], [t;t']) MethodIsUsedWithType(6, m, [t;t'], [t;t']) 
IsUsedMethod(a, n, [t; i']) i->- IsUsedMethod(a, w, [i; t']) 
IsUsedMethod(6,n, IsUsedMethod(6, m, [i; t']) 

IsUsedMethodIn(a, n, y) IsUsedMethodIn(a, m, y) 
IsUsedMethodIn(6, n, y) i-^ IsUsedMethodIn(6, m, y) 
Islnverter(a, n, y, yi) H> Islnverter(a, m, y, yi) 
Islnverter(6, n, y, yi) i—)- Islnverter(6, m, y, yi) 

ExistsMethodInvocation(a, V, VI, n) ^ ExistsMethodInvocation(a, V, VI, m) 
ExistsMethodInvocation(6, V, VI, n) ^ Exist sMethodInvocation(6, V, VI, m) 
IsIndirectlyRecursive(a, n) i— > IsIndirectlyRecursive(a, m) 
IsIndirectlyRecursive(6, n) i— > IsIndirectlyRecursive(6, m) 
BoundVariableInMethodBody(a, n, V) i-> BoundVariableInMethodBody(a, n, V) 
BoundVariableInMethodBody(6, n, V) i->- BoundVariableInMethodBody(6, n, V) 
IsOverridden(a, n) i— > IsOverridden(a, to) 
IsOverridden(6, n) i-^ IsOverridden(6, m) 
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A. 3 AddParameter 



{Add Parameter in Fowler (Fow99j et ;Koc02;) 

AddParameter(class c, method m, parameterType t, parameterName n, defaultvalue e): 

Add a parameter of type t to a method m in class c. In method invocations, use the expression e as new parameter. 



original code 



public class A{ 
public void |m1 ()| { 
blockl } 
public void m2() { 
} 



m1(); 



} 



public class B{ 



refactored code 



public class A{ 



public void m1 (B b) { 
blockl ] 



public void m2(){ 



m1(new B ()); } 



public class B{ 



Refactoring tools. Change Method signature in Eclipse tool and Change Signature in IntelliJ idea. 
A. 4 AddParameterWithReuse 

Overview: AddParameterWithReuse (classname s, subclasses [a,b], methodname m.methodparameters [] .paramType t, 
paramName p, usedvalueofparamType defaultvalue); this operation is used to add the parameter p of type t to the pa- 
rameters of the method s::m, a::m and b::m. Same as AddParameter, but instead of adding a default value for the 
additional parameter in invocations, use any value with the specified type that is visible from the invocation site. 

In IntelliJ IDEA, this is specified with the Any Var option in Change Signature. This is not supported by Eclipse. 

Note that when several variables of the specified type are visible, the result in unspecified. In the example of use in 
this report, the type of the added parameter is a fresh type, and in recursive methods, the only variable of this type is 
the parameter being introduced so that there is not ambiguity. 

Precondition. 

(-iBoundVariableInMethodBody(s, m,p) 

A ExistsClass(s) 

A ExistsMethodDef inition(.s, m) 

A ExistsMethodDef initionWithParains(s, m, []) 

A -lExistsMethodDef initionWithParams(s, m, [t]) 

A -iIsInheritedMethodWithParams(s, m, [t]) 

A -iExistsParameterWithName(s, m, 

A ExistsType(t) 

A AllSubclasses(s, [a; b])) 



Backward Description. 

ExistsMethodDef initionWithParains(s, m, []) H> _L 
ExistsMethodDef initionWithParains(s, m, [t]) M> T 

ExistsMethodDef initionWithParains(a, m, []) M> -lExistsMethodDef initionWithParains(a, m, []) 
ExistsMethodDef initionWithParains(6, m, []) M> -lExistsMethodDef initionWithParajns(6, m, []) 
ExistsMethodDef initionWithParains(a, m, [t]) H> ExistsMethodDef initionWithParams(a, m, []) 
ExistsMethodDef initionWithParains(6, m, [t]) M> ExistsMethodDef initionWithParams(&, m, []) 
ExistsParameterWithNaine(s, m, T 
ExistsParameterWithNaine(a, m, i— )■ T 
ExistsParameterWithNaine(6, m, i— > T 
ExistsParameterWithType(s, m, [t], <) ^ T 
ExistsParaineterWithType(a, rn, [t], i— )■ T 
ExistsParameterWithType(6, TO, [t], t) H> T 
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AllIiivokedMetliodsOnObjectOInBodyDfMAreDeclaredIiiC(s,rn,p, T) i-> T 
AllInvokedMethodsOiiDbjectOInBodyDfMAreDeclaredInC(a, m,p, T) ^ T 
AllInvokedMethodsOiiDbjectOInBodyOfMAreDeclaredInC(&, m,p, T) ^ T 
AllInvokedMethodsWithParameterOInBodyDf MAreNotOverloaded(s, m, p) i-> 

(-iIsDverloaded(s, m) A -iIsDverloaded(a, m) A -ils0verloaded(6, m)) 
AllInvokedMethodsWithParameterOInBodyDf MAreNotOverloaded(a, m, p) ^ 

(-iIsDverloaded(s, m) A -iIsDverloaded(a, m) A -ils0verloaded(6, m)) 
AllInvokedMethodsWithParameterOInBodyDf MAreNotOverloaded(6, m, p) t-> 

(-iIsDverloaded(s, m) A -iIsDverloaded(a, m) A -ils0verloaded(6, m)) 
IsUsedConstructorAsMethodParameter(t, s, to) i—> T 
IsUsedConstructorAsMethodParameter(i, a, m) ^ T 
IsUsedConstructorAsMethodParanieter(t, h, m) i— > T 



A. 5 AddParameterWithDelegate 

original code 



public class A{ 

public void m() { 
blockl 
} 

} 



refactored code 



public class A{ 



public void|m(B b)|{ 
blockl 

} 

p ublic void m() ( 
|m(new B ()); | 

— 

} 



A.6 MoveMethod 



original code 



public class A{ 



public void m(B b){ 
blockl 

} 



} 



public class B{ 



refactored code 




public class B{ 



public void m(A a){ 
[blockl] 

} 



Refactoring tools. If the receiver object is not used in the body of the initial class, it will not be included as parameter 
in the destination class, so that you have to add it (see AddParameter) . 



A. 7 MoveMethodWithDelegate 

{Move Method in Fowler |Fow99] ) 

Overview: MoveMethodWithDelegate (classname s, attributes [attl,att2], targetclass a.methodtobemoved m, parameter- 
stypes [t,a], returntype q, movedmethod n, receivingobjectname o, newreceivingobjectname o'): this operation is used to 
move the method s::m to the class a and rename it as n. 

Transform a method m of a class s into a delegator to a method n in an other class a. The code of m has been moved 
to n (and adapted). 
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original code 



refactored code 



public class A{ 



public void m(B b){ 
blockl 

} 



} 



public class B{ 



public class A{ 



public void m(B b){ 
b.n(this); 

} 



public class B{ 




Refactoring tools. Move in Eclipse tool. In IntelliJ idea, first introduce a local delegate (with Change Signature), 
then Move. 



Precondition. 

(ExistsClass(s) 
A ExistsClass(a) 

A ExistsMethodDef initionWithParELins(s, m, [t; a]) 

A ExistsParcmieterWithType(s, m, [t; a], a) 

A ExistsParcmieterWitliN£mie(s, m, [t; a], o) 

A ^ExistsMethodDef initionWithParams(a, n, [t; s]) 

A HasReturnType(s, m, q) 

A ^IsPrivate(s, to) 

A ^IsPrivate(s, attl) 

A ^IsPrivate(s, att2)) 



Backward Description. 

ExistsMethodDef inition(a, n) i— T 
ExistsMethodDef initionWithParains(a, n, [t; s]) H> T 
HasReturnType(a, n, q) i— HasReturnType(s, m, q) 

ExistsParameterWithNaine(a, n, [t; s], A^) i~> ExistsParameterWithName(s, m, [t; a], A^) {N ^ o) 
ExistsParajiieterWithNcmie(a, n, [t; s], o') i— > T 
ExistsParajneterWithNcmie(a, n, [t; s], o) H> 1. 
ExistsParameterWithType(a, n, [i; s], s) t-^ T 
ExistsParameterWithType(a, n, [i; s], a) ± 

ExistsParameterWithType(a, n, [i; s], T) ^ ExistsParameterWithType(s, m, [t; a], T) (T ^ a) A {T ^ s) 
ExistsMethodInvocation(s, TO, a, n) H- T 
Islnverter(s, m, a, q) T 
IsPrivate(s, attl) i—> ± 
IsPrivate(s, att2) i—> ± 

IsUsedAttributeInMethodBody(s, attl, to) i-^ _L 
IsUsedAttributeInMethodBody(s, att2, to) i->- ± 



A. 8 RenameMethod 

{Rename in Fowler [Fow99| et |Koc02| ) 

RenameMethod(class c, method m, newname n): Rename the method m of class c into n. 
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original code refactored code 



public class A{ 




public class A{ 


puDiic voiQ |nri()K 


>► 


pUDIIC VOID |n(;{ 


blockl 




[blockl] 


} 




} 


} 




} 



Refactoring tools. Rename in Eclipse and IntelliJ idea. 

We have identified two types of this operation. The first one does not accept the overloading, the second one accepts 
overloading. 

A. 8.1 RenamelnHierarchyNoOverloading 

Overview RenamelnHierarchyNoOverloading (class c, subclasses [a, b], method m .types [t,t'], newname n) : this operation 
is used to rename the method (c,a,b)::m into n if n does not already exist with another signature in the hierarchy. 

Precondition. 

(ExistsClass(c) 

A ExistsClass(a) 

A ExistsClass(6) 

A ExistsMethodDef inition(c, m) 

A ExistsMethodDef initionWithPcirams(c, m, [t; t']) 

A AllSubclasses(c, [a; b]) 

A -lExistsMethodDef inition(c, n) 

A ^ExistsMethodDef inition(a, n) 

A -lExistsMethodDef inition(6, n) 

A -lExistsMethodDef initionWithParains(c, n, [t; t']) 

A ^ExistsMethodDef initionWithParams(a, n, [t; t']) 

A -lExistsMethodDef initionWithParams(6, n, [t; t']) 

A -ils0verloaded(c, m) 

A ^IsOverloaded(a, m) 

A -ils0verloaded(6, m) 

A -iIsInheritedMethod(c, n)) 

Backwcird Description. 
ExistsMethodDef inition(c, n) T 

ExistsMethodDef initionWithParams(c, n, [t; t']) T 
ExistsMethodDef inition(a, n) i— ^ ExistsMethodDef inition(a, m) 
ExistsMethodDef inition(6, n) i->- ExistsMethodDef inition(6, m) 
ExistsMethodDef inition(c,m) i-> _L 
ExistsMethodDef inition(a, rn) M- ± 
ExistsMethodDef inition(6, m) h- > _L 

ExistsMethodDef initionWithParams(a, n, >— > ExistsMethodDef initionWithParams(a, m, 

ExistsMethodDef initionWithParams(6, n, [t;t']) ExistsMethodDef initionWithParaiiis(6, m, [t;t']) 

ExistsMethodDef initionWithParams(c, m, [t; i']) >-)■ _L 

ExistsMethodDef initionWithParams(a, TO, [t; t']) h- > _L 

ExistsMethodDef initionWithParams(6, TO, [t; i']) i— > J- 

IsInheritedMethod(a, n) i-> IsInheritedMethod(a, to) 

IsInheritedMethod(6, n) IsInheritedMethod(6, m) 

IsDelegator(c, n, M) ^ IsDelegator(c, m, M) 

IsDelegator(a, n, M) i— > IsDelegator(a, m, M) 

IsDelegator(&, n, M) i-^ IsDelegator(b, to, M) 
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A. 8. 2 RenameOverloadedMethodlnHieretrchy 

Overview RenameOverloadedMethodlnHierarchy (class c, subclasses [a, b], method m ,newname n, types [t]) : this operation 
is used to rename tlie method (c,a,b)::m into n nevertheless n will be overloaded or not. 

Precondition. 

(Exist sClass(c) 

A ExistsMethodDef initionWithParEmis(c, m, [t]) 
A -iIsInheritedMethodWithParains(c, n, [t]) 
A -lExistsMethodDef initionWithParams(c, n, [t]) 
A -lExistsMethodDef initionWithParams(a, n, [t]) 
A -lExistsMethodDef initionWithParams(6, n, [t]) 
A ^IsInheritedMethodWithPcirains(c, m, [t]) 
A AllSubclasses(c, [a; &])) 

Backward Description. 
ExistsMethodDef inition(c, to) i-^ _L 
ExistsMethodDef inition(c, n) i->- T 
IsDverriding(c, n) > _L 
IsOverridden(c, n) i— > _L 
IsPublic(c, n) IsPublic(c, to) 

ExistsMethodDef initionWithParams(c, n, [t]) ExistsMethodDef initionWithParams(c, to, [t]) 

ExistsMethodDef initionWithParains(a, n, [t]) H> ExistsMethodDef initionWithParains(a, to, [t]) 

ExistsMethodDef iiiitionWithParains(6, n, [t]) ExistsMethodDef initionWithParcims(6, to, [t]) 

ExistsMethodDef inition(a, n) i— >■ T 

ExistsMethodDef inition(6, n) t-^ T 

ExistsMethodDef initionWithParains(c, TO, [t]) i->- _L 

ExistsMethodDef initionWithParains(a, TO, [t]) i— > _L 

ExistsMethodDef initionWithParains(6, TO, [t]) i— > _L 

ExistsMethodDef inition(a, to) i-t- _L 

ExistsMethodDef inition(6, to) i-> _L 

isOverridingMethod(a, n, [<]) i—> isOverridingMethod(a, to, [t]) 
isOverridingMethod(6. n, [f]) h- > isOverridingMethod(6, to, [t]) 
ExistsParameterWithNaine(c, n, [i],!^) i— >■ ExistsParaineterWithName(c, to, [i],!^) 
ExistsParameterWithName(a, n, [t],V) i->- ExistsParameterWithName(a, to, [t],V) 
ExistsParameterWithName(6, n, [t],V) i->- ExistsParaineterWithName(6, to, [t],V) 
ExistsParameterWithType(c, n, [f],y) i— ExistsParajneterWithType(c, to, [t],T^) 
ExistsParameterWithType(a, n, [i],!^) i— >■ ExistsParEiineterWithType(a, to, [t],T^) 
ExistsParameterWithType(6, n, [t],V) i->- ExistsParameterWithType(6, to, [t],V) 
IsDelegator(c, n, y) i->- IsDelegator(c, m, F) 
IsDelegator(a, n, F) i-> IsDelegator(a, to, F) 
IsDelegator(6, n, ]/) i— > IsDelegator(5, to, y) 
IsDelegator(c, V, n) i— >■ IsDelegator(c, V, to) 
IsDelegator(a, y,n) i->- IsDelegator(a, V, to) 
IsDelegator(6, y, n) IsDelegator(6, to) 
IsRecursiveMethod(c, n) i— IsRecursiveMethod(c, to) 
IsRecursiveMethod(a, n) i— >■ IsRecursiveMethod(a, to) 
IsRecursiveMethod(6, n) IsRecursiveMethod(&, to) 
ExistsAbstractMethod(c, n) i->- ExistsAbstractMethod(c, to) 
ExistsAbstractMethod(a, n) H> ExistsAbstractMethod(a, to) 
ExistsAbstractMethod(6, n) i— >■ ExistsAbstractMethod(&, to) 
IsInheritedMethodWithParains(a, n, [t]) IsVisibleMethod(c, to, [f], a) 
IsInheritedMethodWithParams(6, n, [f]) i-)- IsVisibleMethod(c, to, [f], 6) 
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MethodIsUsedWithType(c,n, [t], [t]) ^ MethodIsUsedWithType(c, m, [t], [t]) 

MetliodIsUsedWithType(a, n, [t], [t]) ^ MethodIsUsedWithType(a, m, [t], [t]) 

MethodIsUsedWithType(6, n, [t], [t]) H> MethodIsUsedWithType(6, m, [t], [t]) 

IsUsedMethod(c, n, [t]) h->- IsUsedMethod(c, m, [f]) 

IsUsedMethod(a, n, [t]) i->- I sUsedMethod(a, rn, [f]) 

IsUsedMetliod(&, n, [f]) ^ IsUsedMethod(5, to, [i]) 

IsUsedMetliodIii(c, n, ]/) iH> IsUsedMetliodIii(c, to, V") 

IsUsedMethodIii(a, n, y) IsUsedMethodIii(a, to, 

IsUsedMethodIn(6, n, IsUsedMethodIn(6, to, F) 

HasReturnType(c, n, V) i-> HasReturnType(c, to, V) 

HasReturnType(a, n, V) HasReturnType(a, to, V) 

HasReturiiType(6, n, V) ^ HasReturrLType(6, to, V) 

Islnverter(c, n, y, yi) i->- Islnverter(c, to, Fl) 

Islnverter(a, n, V, Fl) Islnverter(a, to, V, 1^1) 

Islnverter(6, n, V, VI) i— >■ Islnverter(6, to, V, Vl) 

ExistsMetliodInvocation(c, V, VI, n) ^ ExistsMetliodInvocation(c, V, VI, to) 
ExistsMethodInvocation(a, V, VI, n) i— > ExistsMethodInvocation(a, V, VI, to) 
ExistsMethodInvocation(6, V, VI, n) i-> ExistsMethodInvocatioii(6, V, VI, to) 
IsIndirectlyRecursive(c, n) i-^- IsIndirectlyRecursive(c, to) 
IsIndirectlyRecursive(a, n) i~> IsIndirectlyRecursive(a, to) 
IsIndirectlyRecursive(6, n) n- IsIndirectlyRecursive(6, to) 
BoundVariableInMethodBody(c, n, V) i-^ BouiidVariableIiiMethodBody(c, n, V) 
BoundVariableInMethodBody(a, n, V) i-)- BouiidVariableIiiMethodBody(a, n, V) 
BoundVariableInMethodBody(6, n, V) n> BouiidVariableIiiMethodBody(6, n, V) 
IsOverridden(a, n) h- > IsOverridden(n, to) 
IsOverridden(6, n) IsOverridden(6, to) 
IsUsedConstructorAsMethodParaineter(V, c, to) _L 
IsUsedConstructorAsMethodParaineter(y, a, to) i-^ _L 
IsUsedConstructorAsMethodParaineter(V, 6, to) _L 

A. 8 . 3 ReneimeDelegator Wit hOver loading 

Overview RenameDelegatorWithOverloading (classname s, subclasses [a,b], method m.paramtype t.paramName pn, super type- 
Ofparamtype t', newname n) : this operation is used to rename the method (c,a,b)::m into n and accepts overloaded 
methods. This operation is an ad-hoc use of the operation RenameOverloadedMethodlnHierarchy (we need in this use more 
details about the signature of the method to be renamed). 

Precondition. 
(ExistsClass(s) 

A ExistsClass(a) 

A ExistsClass(6) 

A ExistsMethodDef inition(s, to) 

A ExistsMethodDef initionWithParams(s, TO, [t]) 

A AllSubclasses(s, [a; b]) 

A -lExistsMethodDef initionWithPaxams(s, n, [t]) 
A -lExistsMethodDef initionWithParcfflis(a, n, [t]) 
A -lExistsMethodDef initionWithParcfflis(6, n, [t]) 
A -iIsInheritedMethod(s, n) 

A -lExistsMethodDef initionWithParains(s,n, [t])) 

Backward Description. ExistsMethodDef inition(s, n) i— )• T 
ExistsMethodDef initionWithParams(s, n, [t]) i— ^ T 
IsPublic(s,n) IsPublic(s, to) 
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ExistsMethodDef iiiition(s, m) i-)- _L 
ExistsMethodDef inition(a. m) _L 
ExistsMethodDef inition(6, to) i— > _L 
ExistsMethodDef initionWithParains(s, TO, [t]) i->- _L 
ExistsMethodDef iiiitionWithParams(a, m, [t]) i->- ± 
ExistsMethodDef initionWithParams(6, TO, [f]) h-> _L 
ExistsMethodDef inition(a, n) h- > ExistsMethodDef iiiition(a, to) 
ExistsMethodDef inition(6, n) i— > ExistsMethodDef iiiition(6, to) 

ExistsMethodDef initionWithParams(a, n, [t]) ExistsMethodDef initionWithParains(a, to, [t]) 
ExistsMethodDef initionWithParams(6, n, [t]) i-^- ExistsMethodDef initionWithParams(6, m, [f]) 
IsIiiheritedMethod(a, n) h- > IsInheritedMethod(a, to,) 
IsInheritedMethod(&, n) M- I s Inherit edMethod(6, to) 
MethodIsUsedWithType(s,n, [t], [t]) h-^ MethodIsUsedWithType(s, to, [t], [t]) 
MethodIsUsedWithType(a,n, [t], [t]) MethodIsUsedWithType(a, to, [t], [t]) 
MethodIsUsedWithType(&, n, [t], [t]) >-> MethodIsUsedWithType(6, to, [t], [t]) 
MethodIsUsedWithType(s,TO, [t], [t]) ^ _L 
MethodIsUsedWithType(a,TO, [f], [t]) H> _L 
MethodIsUsedWithType(6,TO, [i], [t]) _L 

ExistsParameterWithNaiiie(s, n, [t],V) i->- ExistsParaineterWithName(s, to, [t],V) 
ExistsParELmeterWithNcmie(a, n, [t], V^) i— > ExistsParcmieterWithMame(a, to,, [t],!^) 
ExistsParameterWithNcmie(6, n, [t], y) i— >■ ExistsPareimeterWithName(6, to, [t], V^) 
ExistsParameterWithType(s, n, [t],V) i->- ExistsParameterWithType(s, to, [f], V^) 
ExistsParameterWithType(a, n, [f], V) ExistsParameterWithType(a, to, [f], F) 
ExistsParcimeterWithType(6, n, [t], V^) i— > ExistsParcmieterWithType(6, to. 
ExistsMethodInvocation(,s, VI, V. n) ExistsMethodInvocation(.s, VI, V, to) 
ExistsMethodInvocation(o, VI, V, n) H> ExistsMethodInvocation(o, VI, V, to) 
ExistsMethodInvocation(6, VI, V, n) i-> ExistsMethodInvocation(6, VI, V, to) 
IsDelegator(s, n, F) i-> IsDelegator(s, to, F) 
IsDelegator(a, n, V^) i— > IsDelegator(a, to, V) 
IsDelegator(6, n, y) i— > IsDelegator(fe, to, 1/) 
IsDelegator(s, n) IsDelegator(s, to) 
IsDelegator(a, V, n) IsDelegator(a, F, to) 
IsDelegator(6, V, n) i— > IsDelegator(5, V, to) 
IsUsedMethod(s, n, [t]) IsUsedMethod(s, to, [t]) 
IsUsedMethod(a, n, [<]) t-^ IsUsedMethod(a, to, [f]) 
IsUsedMethod(6,n, [t]) IsUsedMethod(6, to, [t]) 
IsUsedMethodIn(s, n, y) IsUsedMethodIn(s, to, V) 
IsUsedMethodIii(a, n, y) ^ IsUsedMethodIii(a, to, F) 
IsUsedMethodIn(6, n, y) i-)- IsUsedMethodIn(6, to, F) 
HasReturnType(s, n, V) HasReturnType(s, to, F) 
HasReturnType(a, n, y) i->- HasReturnType(a, to, F) 
HasReturnType(6, n, V) H- HasReturnType(5, to, V) 
Islnverter(s, n, y, yi) H- Islnverter(s, to, Fl) 
Islnverter(a, n, V, VI) Isliiverter(a, to, V, F1) 
Islnverter(6, n, V, VI) Islnverter(6, to, V, VI) 
IsIndirectlyRecursive(s, n) IsIndirectlyRecursive(,s, to) 
IsIndirectlyRecursive(a, n) h- > IsIndirectlyRecursive(a, to) 
IsIndirectlyRecursive(6, n) i— )■ IsIndirectlyRecursive(6, to) 
BoundVariableInMethodBody(s, n, V) i-> BoundVariableInMethodBody(s, n, V) 
BoundVariableInMethodBody(a, n, V) BouiidVariableIiiMethodBody(a, n, V) 
BoundVariableInMethodBody(&, n, V) i~->- BoiiiidVariableIiiMethodBody(6, n, V) 
IsOverridden(a, n) i— >■ IsOverridden(a, m) 
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IsOverridden(6, n) IsDverriddeii(6, m) 
IsUsedConstructorAsMethodParameter(V, s, m) M> _L 
IsUsedConstructorAsMethodParameter(V, a, m) i—> _L 
IsUsedConstructorAsMethodParameter(y, 6, m) i— > _L 

A. 9 ExtractSuperClass 

{Extract Super Class in Fowler |Fow99j and jKoc02] ) 

Overview: ExtractSuperClass (subclasses[a,b], superclass s.methodsOfsubclasses [m,n],returntype t): this operation is used 
to extract a super-class s from the classes a and b and make an abstract declaration of methods a::m, a:m, b::m and b::n 
in this new super-class. 

original code refactored code 

abstract class S{ 
abstract void m(); 



} 



class A{ 
void m(){...} 

void na(){...} 

} 




class A extends S { 
void m(){...} 

void na(){...} 

} 


>■ 


class B{ 
void m(){...} 

void nb(){...} 

} 




class B extends S { 
void m(){...} 

void nb(){...} 

} 



Refactoring tools. Extract Superclass in Eclipse tool and IntelliJ idea. In IntelliJ idea, the Extract Superclass 
operation cannot be applied to several classes simultaneously, so we have maintain the code of this operation in order to 
run it on several classes. 

Precondition. 

(-iexistsType(s) 
A ExistsClass(a) 
A ExistsClass(6) 

A ExtendsDirectly(a, java.lang.Object) 
A ExtendsDirectly(6, java.lang.Object) 
A HasReturnType(a, to, t) 
A HasReturnType(a, n, t) 
A HasReturnType(6, to, t) 
A HasReturnType(&, ri, t)) 

Backward Description. 

IsAbstractClass(s) M> T 
ExistsClass(s) H> T 
ExistsType(s) ^ T 

ExistsMethodDef inition(s, X) H> (ExistsMethodDef inition(a, X) 
A ExistsMethodDef inition(5, X)) 

ExistsMethodDef initionWithParains(s, X, []) H> (ExistsMethodDef initionWithParEims(a, X, []) 
A ExistsMethodDef initionWithParains(6,X, [])) 

ExistsMethodDef initionWithParains(s,X, [Y]) ^ (ExistsMethodDef initionWithParams(a, X, [Y]) 
A ExistsMethodDef initionWithParams(6,X, [Y])) 
IsUsedMethodIn(s,X, r) ^ _L 
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ExistsMethodDef iiiitionWithParams(X, y, [s]) i-^ _L 

IsUsedMethod(s,X, [F]) ^ ± 

AllSubclasses(s, [a; 6]) T 

MethodIsUsedWithType(X,y, [Z], [s]) H> ± 

IsInheritedMethodWithParains(X,y, [s]) _L 

IsUsedConstructorAsMethodParameter(s, X, F) i— > _L 

IsUsedConstructorAsInitializer(s, X, y) H> ± 

IsUsedConstructorAsObjectReceiver(s, X, y) i— > _L 

IsPriinitiveType(s) _L 

IsSubType(a, s) i->- T 

IsSubType(6, s) i— T 

IsSubType(X, s) i-)- IsSubType(X, a) 

IsSubType(X, s) IsSubType(X, 6) 

IsPublic(s, m) i->- T 

IsPublic(.s, n) ^ T 

ExistsAbstractMethod(s, m) h-^ T 

ExistsAbstractMethod(s, n) i— > T 

IsOverriding(s, m) i->- _L 

IsOverriding(s, n) _L 

IsDverridden(s, to) i— > T 

IsOverridden(s, n) i— > T 

IsPrivate(s, to) _L 

IsPrivate(s,n) i->- _L 

A.9.1 ExtractSuperClassWithoutPuUUp 

Overview: ExtractSuperClassWithouPullUp (subclasses[a,b], superclass s): this operation is a specific variant of the op- 
eration extract super-class. It is simply used to extract a super-class without pull up the methods of sub-classes. 

Precondition. 

(-iExistsType(s) 
A ExistsClass(a) 
A ExistsClass(6) 

A ExtendsDirectly(a, java.lang.Object) 
A ExteiidsT)iTectly{b, java.lang.Object)) 

Backward Description. 

IsAbstractClass(s) i— > T 
ExistsClass(s) i->- T 
ExistsType(s) i-)- T 
AllSubclasses(s, [a; 6]) i— >• T 
IsSubType(a, s) i— ?• T 
IsSubType(6, s) i-^ T 
IsSubType(X, s) IsSubType(X, a) 
IsSubType(X,s) IsSubType(X, 6) 

A. 10 GeneralisePcirameter 

Overview: GeneraliseParameter (classname s, subclasses [a,b], methodname m.paramName p.type t .supertype st): this 

operation is used to change the type t of the parameter p of the methods s::m, a::m and b::m into a super- type st. All the 
uses of the parameter which type is changed must be legal with the new type st (method invocations, object passed as 
parameter of other methods). The uses of the parameter which type is changed as parameter of methods must not result 
in a charge of the invoked code (static resolving of overloading). 
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original code 



refactored code 



class A{ 
void m(B b)|{ 
blockl 

} 

} 



class C { 



class B extends C { 



class A{ 
void nT(Cb]{ 
blockl 

} 

} 



class C { 



class B extends C { 



Refactoring tools. Change Method Signature in Eclipse tool and Type Migration in IntelliJ idea (or Change Signature). 

Precondition. 

(Exist sClass(s) 

A ExistsClass(a) 

A ExistsClass(6) 

A ExistsMethodDef inition(s, m) 

A ExistsMethodDef inition(a, m) 

A ExistsMethodDef inition(6, m) 

A IsSubType(st, t) 

A AllSubclasses(s, [a; b]) 

A IsLocalInvokedMethod(s, m,p, t) 

A IsLocalInvokedMethod(a, m, p, t) 

A IsLocalInvokedMethod(6, m,p, t) 

A NotInvolvedInOverlaodingResolution(s, m,p) 

A MotInvolvedInOverlaodingResolution(a, m,p) 

A NotInvolvedInOverlaodingResolution(&, m,p)) 



Backward Description. 

Islnverter(s, TO, y) i->- Islnverter(s, m, si, 
Islnverter(a, m, t, F) i->- Islnverter(a, to, st, F) 

Islnverter(6, TO, T^) i— >■ Islnverter(&, m, sf, T^) 

ExistsMethodDef initionWithParams(.s, TO, [t]) ^ ExistsMethodDef initionWithParams(,s, to, [st]) 
ExistsMethodDef initionWithParams(a, TO, \t\) i— > ExistsMethodDef initionWithParams(a, to, [st]) 
ExistsMethodDef initionWithParains(6, TO, \t]) ^ ExistsMethodDef initionWithParams(6, to, [st]) 
ExistsMethodDef initionWithParains(s, TO, [st]) ^ _L 
ExistsMethodDef initionWithParams(a, TO, [st]) i— >■ _L 
ExistsMethodDef initionWithParains(6, TO, [st]) i-> _L 
IsInheritedMethodWithParains(a, TO, [t]) ^ T 
IsInheritedMethodWithParaiiis(6, TO, [t]) ^ T 
IsUsedConstructorAsMethodParameter(t, s, to) H> T 
IsUsedConstructorAsMethodParameter(t, a, to) h-^ T 
IsUsedConstructorAsMethodPEirameter(t, 6, to) i— >■ T 
IsUsedConstructorAsMethodParameter(st, s,to) ^ _L 
IsUsedConstructorAsMethodPciraineter(st, a, to) i— > _L 
IsUsedConstructorAsMethodParameter(st, 6, to) ^ _L 
IsOverridden(a, to) i— > ExistsMethodDef inition(a, to) 
IsOverridden(&, to) ^ ExistsMethodDef inition(6, to) 
IsOverriding(a, to) ^ ExistsMethodDef inition(a, to) 
IsOverriding(6, to) ^ ExistsMethodDef inition(6, to) 
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ExistsParameterWithName(s,m, i-> T 

ExistsParajneterWithNELine(a, TO, i— > T 

ExistsParameterWithNEiine(6, TO, i— t- T 

ExistsParameterWithType(s, TO, [t], h->- T 

ExistsParameterWithType(a, TO, i->- T 

ExistsParameterWithType(6, TO, i-^- T 



A. 11 MergeDuplicateMethods 

Overview MergeDuplicateMethods (classname c, subclasses [a,b],mergedmethods [m,n],newmethod m2, invertedtype t, 

returntype q): this operation is used to merge methods m and n existing in the hierarchy to a single method m2. The 
formal description of this operation is built on the formal description of five refactoring operations since it is composed 
of these operations. 



Algorithm of the operation The operation MergeDuplicateMethods is based on four steps 



MergeDuplicateMethods (c,[a,b],[m,n],m2,t,q) = 

1. ReplaceMethodcodeDuplicateslnverter (c, m, [n], t,q)) 

2. PullupConcreteDelegator(c, [a,b], n ,m)) 

3. lnlineAndDelete(c,n)) 

4. RenamelnHierarchyNoOverloading (c, [a,b], m,[t], m2) 



initial code 



public abstract class S { 

public abstract void m1 (); 
public abstract void m2(); 

} 



public class A extends S { 



public void m1 (){ 
block 



public void m2(){ 
block } 



public class B extends S { 



public void m1 (){ 
block } 



public void m2(){ 
block } 



refactored code 



public abstract class S { 
public abstract void m(); 



} 



public class A extends S { 



public void m(){ 
block } 



} 



public class B extends S { 



public void m(){ 
block } 



} 



Refactoring tools. Rename, Replace Method duplication, Extract Method, In-line in Eclipse, Rename, Replace Method 
Code Duplicates, Pull Up, Inline in IntelliJ idea: 



Notes. 



• ReplaceCodeDuplicates introduces a delegation. After that, the code for m2 is the same in all the subclasses of c (a 
delegation). Then the pull-up can be done without changing the semantics, which allows to inline (and remove) m2 
afterwards. 

• After the first pull-up, the IntelliJ idea pull-up warns that some code already exists. The first time, when some 
code replaces the abstract declaration, the refactorer manages to remove the abstract declaration. The next times. 



44 



when a second code comes in addition of the first one, the refactorer prefers to leave the two versions (which are 
identical in this case), so that we have to use safe delete to remove one of them. 

We could provide an extension of the pull-up operation with the customized behavior. 
Preconditions: 

• The two concerned methods bodies must be syntactically equals. 

• The new name must not introduce an overloading. 

• The two methods must not be overloaded. 

A. 12 ReplaceMethodcodeDuplicatesInverter 

Overview ReplaceMethodcodeDuplicateslnverter (classname c, method m, copies [n,ml],invertedtype t,returntype q) : this 
operation is used to replace c::[n,ml] by c::m. 

Precondition. 

(ExistsClass(c) 

A (ExistsMethodDef inition(c, m) 
A ExistsMethodDef inition(c, n) 
A ExistsMethodDef inition(c, ml)) 
A (Islnverter(c, m, t, q) 
A Islnverter(c, n, t, q) 
A Islnverter(c, ml, t, q))) 

Backward Description. 

IsDelegator(c, n, m) T 
IsDelegator(c, ml,m) i-> T 
ExistsMethodInvocation(c, n, c, m) h- > _L 
ExistsMethodInvocation(c, ml, c, m) h- >■ _L 
IsRecursiveMethod(c, n) i— > _L 
IsRecursiveMethod(c, ml) _L 

A. 13 SafeDeleteDelegatorOverriding 

Overview SafeDeleteDelegatorOverriding (classname c, method m, superclass s, deleguee n) : this operations is used to 
remove useless overridings. 

Precondition. (ExistsClass(c) 

A ExistsClass(s) 

A ExistsMethodDef inition(c, m) 

A ExistsMethodDef inition(s, m) 

A IsDelegator(c, m, n) 

A IsDelegator(s, m, n) 

A NotInvolvedInOverlaodingResolution(c, m, this)) 

Backward Description. 
ExistsMethodDef inition(c, m) i— > _L 
IsInheritedMethod(c, m) i-> T 

AllInvokedMethodsOnObjectOInBodyOfMAreDeclaredInC(c,m,X, F) i-^ ± 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(c, m, X) _L 
BoundVariableInMethodBody(c, m, X) i— )■ _L 
ExistsParaineterWithName(c, m, [X], y) _L 
ExistsParaineterWithType(c, m, [X], y) i-^ _L 
ExistsMethodInvocation(c, m, X, y) i-^ _L 
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ExistsMethodDef iiiitionWithParams(c, m, [X]) i-^ _L 
IsIiilieritedMethodWithParams(X, m, [y]) _L 
IsIndirectlyRecursive(c, m) i— > _L 
IsVisibleMethod(c,m, h^- _L 

Islnverter(c, m, X, F) >->• ± 
IsDelegator(c. m, X) i-t- ± 
IsUsedMet]iod(c, m, [X]) ± 
IsUsedMethodIii(c, TO, X) i->- _L 

IsUsedConstructorAsMethodParaineter(X, c, to) i-> _L 
IsUsedConstructorAsInitializer(X, c, to) i-> _L 
IsUsedConstructorAsObjectReceiver(X, c, to) _L 
IsPublic(c, to) _L 
IsProtected(c, to) H- ± 
IsPrivate(c, to) _L 

IsUsedAttributeInMethodBody(c, X, to) i-)- _L 
IsDverridderL(c, m) H> ± 
IsOverloaded(c, to) h- > _L 
IsOverriding(c, to) i-> _L 
IsRecursiveMethod(c, to) i-> _L 
HasReturnType(c, to, X) i— 5- ± 
MethodHasParameterType(c, to, X) _L 
MethodIsUsedWithType(c,TO, [X], [X]) _L 



A. 14 PullUpAbstract 



PullUpAbstract(set of classes C, method m, interface s) 

Pull up a method implemented in a set of classes C to their superclass s: do not move the definitions, just declare the 
method abstract in s. 



original code 



public class A { 



class B extends A { 



public void m(){ 
blockl 
} 



refactored code 



public class A { 



abstract void m() 



class B extends A { 

public void m(){ 
blockl 

} 

} 



Refactoring tools. Pull Up in Eclipse tool and IntelliJ idea. 

Preconditions: 

• s is a superclass of each class in C. 



• m is defined in all the classes of C 
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A. 15 PuUUpImplementation 



Overview: Pulluplmplementation(a,[attl,att2],m,s): this operation is used to pull up the definition of the method a::m 
to s and delete it from a. 



original code 



public class A { 



refactored code 



public class A { 



public void m(){ 
blockl 

} 



class B extends A { 



public void m(){ 
blockl 

} 



class B extends A { 



Refactoring tools. Pull Up in Eclipse tool and IntelliJ idea. 

Precondition. 

(ExistsClass(a) 

A ExistsClass(s) 

A IsAbstractClass(s) 

A ExistsMethodDef inition(a, m) 

A ExistsAbstractMethod(s, m) 

A AllInvokedMethodsOnOb j ectOInBodyOf MAreDeclaredInC(a, m, this, s) 

A AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(a, m, this) 

A ->IsPrivate(a, m) 

A -iIsUsedAttributeInMethodBody(a, attl, m) 
A -iIsUsedAttributeInMethodBody(a, att2, m)) 



Backward Description. 
ExistsMethodDef inition(a, m) ^ _L 
ExistsMethodDef inition(s, m) i->- T 
ExistsAbstractMethod(s, to) _L 

IsDelegator(s, TO, X) i—> IsDelegator(a, m, X) {rn, =/= X) 
ExistsMethodDef initionWithParams(a, TO, [X]) i— > _L 
ExistsMethodDef initionWithParains(s, TO, [X]) i->- T 
IsI]iheritedMethodWithParams(a, m, [X]) >->• T 
IsInheritedMethod(a, to) i— > T 
IsVisibleMethod(s,TO, [X],a) T 
IsPrivate(a, to) h->- _L 
IsOverridden(a, to) _L 
IsOverriding(a, to) i— > -L 
IsVisible(s, TO, a) i— > T 

IsOverloaded(s, to) i— >■ ExistsMethodDef inition(s, to) 
IsUsedAttributeInMethodBody(a, X, m) i->- _L 
IsOverridden(a, to) i-^ _L 
IsDverloaded(a, to) > _L 
IsRecursiveMethod(a, to) i— > _L 
HasReturnType(a, TO, X) i->- _L 
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Method.HasParEimeterType(a, m, X) M> 1. 
MethodIsUsedWithType(a, m, [X], [X]) ^ _L 
IsPrivate(a, attl) M- _L 
IsPrivate(a, att2) i— >■ _L 



A. 16 PullUpWithGenerics 



Overview: PullupWithGenerics (classname s, subclassname a, [attl,att2],methodname m.returntype RT .parameterType T): 

this operation is used to pull up the method a::m to s and then creates the parameter type T to the class s (as shown in 
the following figure). After performing this operation a polymorphism is created in the hierarchy (Java Generic types). 



original code 



public class A { 



class B extends A { 



public V m(){ 
blockl 
} 



class C extends A { 



public W m(){ 
block2 
} 



refactored code 



public class A <T> { 




abstract <T> T m() 



class B extends A <V> { 



public V m(){ 
blockl 
} 



class C extends A <W> { 



} 



public W m(){ 
block2 

} 



Refactoring tools. We provide this operation as a plugin for IntelliJ idea {Pull up method refactoring extension: 
http : //plugins . intellij ■net/plugin/?idea_ce&id=6889 ). 

Precondition. 

(ExistsClass(s) 

A IsAbstractClass(s) 

A ExistsClass(a) 

A IsSubType(a, s) 

A -iExistsAbstractMethod(s, m) 

A AllInvokedMethodsOnOb j ectOInBodyOf MAreDeclaredInC(a, m, this, s) 

A AllInvokedMethodsWithParameterOInBodyDf MAreNotDverloaded(a, m, this) 

A -iIsPrimitiveType(i?r) 

A -iHasParameterType(a, RT) 

A (-iIsUsedAttributeInMethodBody(a, attl, m) V -iIsPrivate(a, attl)) 
A (-iIsUsedAttributeInMethodBody(a, att2, m) V -iIsPrivate(a, att2))) 



Backward Description. 

ExistsAbstractMethod(s, m) i— )> T 
HasReturnType(s, m, T) i— > T 
MethodHasParameterType(s, rn, T) i-^ T 
HasParameterType(s, T) i— > T 
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extend.sFromPrametricClass(a, s, i?T) t-^ T 
IsGenericsSubtype(a, [-RT], s, [T]) t— T 
IsPrivate(a, to) i— > _L 
IsDverridden(a, m) ^ T 
IsOverriding(a, m) ^ T 

A. 17 InlineAndDelete 

{Inline Method in |Fow99] ) 

Overview: InlineAndDelete (classname s.methodname m): this operation is used to replace one or all invocations of a 
given method by its body and delete it. 



original code 


refactored code 


class A { 




class A { 


public void m1(){ 
blockl-1 ; 
m2(); 
block1-2 ; 
} 




public void m1(){ 
blockl-1 ; 
block2; 
block1-2 ; 
} 


public void m2(){ 
block2 ; — 

} 




} 



Refactoring tools. In-line in Eclipse tool and IntelliJ idea. 

Precondition. 

(Exist sClass(c) 

A ExistsMethodDef inition(c, to) 

A ^IsOverriding(c, to) 

A ^IsOverridden(c, to) 

A ^IsRecursiveMethod(c, to)) 

Backward Description. 

ExistsMethodDef inition(s, to) i— >■ _L 
ExistsMethodDef initionWithParams(s, TO, []) h- > _L 

AllInvokedMethodsOnObjectOInBodyDfMAreDeclaredInC(s,TO,X, y) _L 

AllInvokedMethodsWithParameterQInBodyOf MAreNotOverloaded(s, m, X) _L 

BoundVariableInMethodBody(s, TO, X) ± 

ExistsParameterWithNaine(s, TO, [X], y) H> _L 

ExistsParameterWithType(s, TO, [X], y) H- ± 

ExistsMethodInvocation(s, TO, X, y) ^ ± 

ExistsMethodDef initionWithParains(s, TO, [X]) i— > _L 

IsInheritedMethodWithParains(X, TO, [y]) ± 

IsIndirectlyRecursive(s, to) i-> _L 

IsVisibleMethod(s,TO, [X],y) i-^ _L 

Islnverter(s, TO, X, y) i— >■ _L 

IsDelegator(s, TO, X) i— > _L 

IsUsedMethod(s, TO, [X]) ^ _L 

IsUsedMethodIn(s, TO, X) ± 

IsUsedConstructorAsMethodParcmieter(X, s, m) i— > _L 
IsUsedConstructorAsInitializer(X, s, to) i— > _L 
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IsUsedConstructorAsObjectReceiver(X, s,m) _L 
IsPublic(s, m) i— > ± 
IsProtected(s, m) i— >■ _L 
IsPrivate(s, to) i->- ± 

IsUsedAttributeIiiMethodBody(s,X, to) i->^ _L 
IsOverridden(,s, to) i— )■ _L 
IsOverloaded(s, to) h- > _L 
IsOverriding(s, to) i— t- _L 
IsRecursiveMethod(s, to) _L 
HasReturnType(s,TO, X) i-^- _L 
HasParameterType(,s, TO.) h- > _L 
MethodHasParameterType(s, TO, X) i— >■ _L 
MethodIsUsedWithType(s,TO, [X], [X]) i-)- _L 

A. 18 InlineMethodlnvocations 

Overview: lnlineMethodlnvocations(classname c.inlinedmethod m, classofinlinedmethod a, modifiedmethod n): this opera- 
tion is used to in-line a method invocation of the method c::m inside the method a::n. 

original code refactored code 

class A { 

public void m1(){ 
blockl-1 ; 
^ blo ck2; ~\ 
block1-2 ; 

} 

public void m2(){ 
block2 ; } 

} 



Refactoring tools. Inline in Eclipse and IntelliJ IDEA: select an invocation to inline and specify you want to inline 
only that one. 

Precondition. 

(Exist sClass(c) 

A IsIndirectlyRecursive(c, n) 

A ExistsMethodInvocation(c, n, a, to) 
A ExistsMethodDef inition(c, n)) 

Backward Description. 

ExistsMethodInvocation(c, TO, a, n) i->- _L 

IsRecursiveMethod(c, to) i-> ExistsMethodInvocation(a, n, c, to) 

IsIndirectlyRecursive(c, TO,) M- (ExistsMethodInvocation(a, n, C, X) 
A ExistsMethodInvocation(C, X, c, to)) {X ^ to) 
IsUsedMethodIn(a, n, to) >-> _L 

A. 19 AddSpecializedMethodlnHierarchy (Composed) 

Overview: AddSpecializedMethodlnHierarchy(class s, subclasses [a,b], methodname m, callermethods [n,o], inkovekmethods 
[p,q], paramtype t, paramname pn , subtypesOfparamtype [tl,t2],newtype t'): this operation is used to get the method s::m(t' 
pn) instead of s::m(t pn). This new duplication takes place in s and in all its subclasses that override m. 




class A { 

public void m1(){ 
blockl-1 ; 
m2(); 
block1-2 ; 

} 
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original code 



refactored code 



public class A { 



public void m(B){ 
blockl 

} 




public class B extends C{ 
} 



public class A { 



public void m(B){ 
blockl I 



public void m(C){ 
blockl } 



public class C{ 

} 



public class B extends C{ 
} 



Algorithm of the operation The operation AddSpecializedMethodlnHierarchy is based on three steps : 



AddSpecializedMethodlnHierarchy(class s, subclasses [a,b], methodname m, callermethods [n,o], inkovekmethods [p,q], param- 
type t, paramname pn , subtypesOfparamtype [tl,t2],newtype t') — 

1. DuplicateMethodlnHierarchy s [a,b] m [p,q] [n,o] temporaryName [t] 

2. SpecialiseParameter s [a,b] temporaryName t pn [tl,t2] t'; 

3. RenameDelegatorWithOverloading (s, [a,b], temporaryName, t', pn,t,m) 



Refactoring tools. With IntelhJ idea: 

1. Apply DuplicateMethodlnHierarchy(c, m, temp-name) (see IA.201 below). 

2. Apply Change Signature on the method temp-name in the class s, to change the parameter type t into t' (this change 
is propagated into subclasses). 

Note that the behavior preservation is not guaranteed by this operation in general, but here we introduce a new 
method so the behavior is not changed. Note also, that here we cannot use the operation Type Migration of IntelliJ 
IDEA: replacing a parameter type by one of its subtypes is not safe in general. 

3. Rename temp-name into m in s with Rename. That renaming introduces an overloading. In general, this could 
change the semantics of the program, but in the case of this particular chain, and provided the preconditions given 
below are satisfied, the behavior is preserved (the two methods have the same body; some invocations may be 
dispatched on the new method, but the external behavior is the same). 

A. 20 DuplicateMethodlnHierarchy 

Overview: DuplicateMethodlnHierarchy(class s, subclasses [a,b], methodname m, callermethods [ml,m2], inkovekmethods 
[p,q],newname n .paramType [t]) : this operation is used to create a duplicate of the method s::m with the name n. All 
overriding methods in subclasses are also duplicated in these classes. 

Refactoring tools. With IntelhJ idea: 

1. For each implementation of the method m in the subclasses of the class s, duplicate m by applying Extract Method 
on its body (give the new name, specify the desired visibility), then inline the invocation of method n that has 
replaced the method's body. 

2. Use Pull Members Up to make the new method appear in classes where the initial method is declared abstract 
(specify that it must appear as abstract) (see PullUp Abstract). 

Precondition. 

(Exist sClass(s) 

A ExistsMethodDef initionWithParcmis(s, m, [t]) 

A ExistsMethodDef inition(s, m) 

A ^ExistsMethodDef initionWithParams(s, n, [t]) 
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A ^ExistsMethodDef initionWithParams(a, n, [t]) 
A -lExistsMethodDef initionWithParams(6, n, [t]) 
A -•IsInheritedMethodWithParains(s,n, [t]) 
A AllSubclasses(s, [a; b])) 

Backward Description. 

ExistsMethodDef initioii(.s. T?) h-> T 
ExistsMethodDef initionWithParains(s, n, [t]) f-> T 

AllInvokedMethodsWithPciraiiieterOInBodyOf MAreNotOverloaded(s, n,V) i-^ T 

{size{invokedmethodsInmethodname) 

AllInvokedMethodsOnObjectOInBodyOf MAreDeclaredInC(s, n, V, VI) ^ 

AllInvokedMethodsOnObjectOInBodyOf MAreDeclaredInC(s, to, V, 
BoundVariableInMethodBody(s, n, V) BoundVariableInMethodBody(s, m, V) 
IsPublic(s,n) i-^- IsPublic(s,TO) 

ExistsParajiieterWithNcmie(s, n, [t], V) M- ExistsParajiieterWithNaine(s, m, [t], V) 
ExistsParameterWithType(s, n, [t],!^) i-> ExistsParameterWithType(s, to, 
IsIndirectlyRecursive(s, n) i->- IsIndirectlyRecursive(s, to) 
IsRecursiveMethod(s, n) i-> IsRecursiveMethod(s, to) 

Islnverter(s, n, T, T^) i— > Islnverter(s, to, T, T^) 

IsUsedAttributeInMethodBody(s, V, n) ^ IsUsedAttributeInMethodBody(s, V,m) 
MethodHasParameterType(s, n, y) i— )■ MethodHasPar£mieterType(s, to, V") 

ExistsMethodDef iiiitionWithParams(a, n, \t\) i->- ExistsMethodDef initionWithParams(a, to, \t]) 

ExistsMethodDef iiiitionWithParams(6, n, \t]) i->- ExistsMethodDef initionWithParams(6, to, \t]) 

IsDelegator(s, n,|?) H> T 

IsDelegator(s, n, g) i— >■ T 

IsDelegator(a, n,p) i— T 

IsDelegator(a, n, g') ^ T 

IsDelegator(6, r7.p) h-> T 

IsDelegator(/j, n. 5) h-^ T 

ExistsMethodDef inition(s, n) M> T 

ExistsMethodDef inition(a, n) i->- T 

ExistsMethodDef inition(6, n) T 

MethodIsUsedWithType(.s,n, [t], [t]) ^ L 

MethodIsUsedWithType(a, n, [t], [t]) i-> _L 

MethodIsUsedWithType(&,n, [t], [<]) i->- _L 

MethodIsUsedWithType(s,n, [t], [T]) i->- _L 

MethodIsUsedWithType(a,n, [i], [T]) 1-^ _L 

MethodIsUsedWithType(fe, n, [t], [T]) ^ _L 

ExistsMethodInvocation(s, toI, y, n) 1— >■ T 

ExistsMethodInvocation(s, to2, y, n) i->- T 

ExistsMethodInvocation(a, toI, V, n) ^ T 

ExistsMethodIiivocation(a, to2, V, n) T 

ExistsMethodInvocation(6, toI, y, n) 1— >■ T 

ExistsMethodInvocation(6, m2, V,n) i-> T 

IsInheritedMethodWithParams(a, n, [t]) i-> -lExistsMethodDef initionWithParams(a, to, \t]) 
IsInheritedMetliodWithParams(6, n, H. ^ExistsMethodDef iiiitionWithParains(6, to, [t]) 
IsInheritedMethod(a, n) 1— > -lExistsMethodDef inition(a, to) 
IsInheritedMethod(6, n) t-> -lExistsMethodDef inition(6, to) 
IsOverriding(a, n) i-)- -lExistsMethodDef inition(a, to) 
IsOverriding(6, n) i— > -lExistsMethodDef inition(6, to) 
IsOverridden(a, n) h- > ^ExistsMethodDef inition(a, to) 
IsOverriddeii(6, n) 1— )■ -lExistsMethodDef inition(6, to) 
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A. 21 DeleteMethodlnHierarchy 

{Delete Method in Fowler |Fow99) and |Koc02j ) 



Overview: DeleteMethodlnHierarchy (classname s, subclasses [a,b], method m, invokedmethodslnm [ml,m2], paramType 

t) : this operation is used to delete the method m from the hierarchy of classes s, a and b. 



original code refactored code 



public class A{ 

public abstract void m1 {){ 

} 





public class A{ 

public abstract void m1 (){ 

} 


puDiic aDstract voia rm(}\ 
i 











public class B extends A{ 
public void m1 (){ 
blockl } 


>► 


public class B extends A{ 
public void m1 (){ 
blockl } 


public void m2(){ 
block2 } 











public class C extends A{ 
public void m1 (){ 
blockl } 





public class C extends A{ 
public void m1 (){ 
blockl } 


public void m2(){ 
block2 } 






} 


1 



Refactoring tools. Safe Delete in IntelliJ IDEA and Delete in Eclipse. 

Precondition. 

(ExistsClass(s) 

A ExistsMethodDef initionWithParELins(s, m, [t]) 
A -•MetliodIsUsedWithType(s, m, [t], [t]) 
A ^MetliodIsUsedWitliType(a, m, [t], [t]) 
A ^MetliodIsUsedWitliType(6, m, [t], [t]) 
A AllSubclasses(s, [o; b])) 

Backward Description. 

ExistsParameterWithType(s, m, [i], t) H> _L 

ExistsParameterWithType(a, TO, [t], i) h- > _L 
ExistsParcimeterWithType(6, TO, [i], i) h- > _L 
ExistsMethodDef initionWithParams(s, TO, [<]) _L 
ExistsMethodDef initionWithParams(a, TO, [i]) _L 
ExistsMethodDef initionWithParams(5, TO, [i]) _L 
ExistsMethodDef inition(s, to) i— > _L 
ExistsMethodDef inition(a, to) _L 
ExistsMethodDef inition(6, to) i— > _L 
IsUsedMethod(s,TOl, [yi]) ^ ± 
IsUsedMethod(s,TO2, [yi]) ^ ± 
IsUsedMethod(a, toI, [yi]) ^ _L 
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IsUsedMethod(a,m2, [yi]) ^ _L 

IsUsedMethod(6, ml, [yi]) ^ ± 
IsUsedMethod(6,m2, [yi]) ^ ± 

IsUsedConstructorAsMethodParaineter(yi,s,rn) i->- _L 
IsUsedConstructorAsMethodParameter(Fl, a, m) _L 
IsUsedConstructorAsMethodPcirameter(Fl, 6, m) i— > _L 
IsUsedConstructorAsMethodParameter(t, s, m) H> ± 
IsUsedConstructorAsMethodPEirameter(t, a, m) i— > _L 
IsUsedConstructorAsMethodParameter(t, 6, m) i->- _L 
IsUsedConstructorAsObjectReceiver(f, s, m) i->- _L 
IsUsedConstructorAsDbjectReceiver(t, a, m) i-^ _L 
IsUsedConstructorAsDbjectReceiver(t, 6, to) h- >■ _L 
IsIiilieritedMethod(a, to) _L 
IsInheritedMethod(6, to) _L 

AllInvokedMethodsOnDbjectOInBodyOf MAreDeclaredIiiC(s, to, VI, V2) ^ ± 
AllInvokedMethodsOnDbjectOInBodyDf MAreDeclaredInC(a, to, VI, V2) i-> _L 
AllInvokedMethodsOnObjectOInBodyOfMAreDeclaredIiiC(6, TO, VI, V2) i-^ _L 
ExistsAbstractMethod(s, to) _L 
ExistsAbstractMethod(a, to) i->- _L 
ExistsAbstractMethod(&, to) _L 

AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(s, TO, VI) _L 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(a, to, VI) i-> _L 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(6, to, VI) i-> _L 

BoundVariableInMethodBody(s, TO, Fl) _L 
BoundVariableInMethodBody(a, TO, \^1) i-> ± 
BoundVariableInMethodBody(6, TO, yi) _L 
ExistsParameterWithNaine(s, TO, [t], yi) i->- _L 
ExistsParaiiieterWithName(a, TO, [f], t^l) i-)- _L 
ExistsParameterWithNajne(6, TO, [t], t^l) i— >■ _L 
ExistsMethodInvocation(s, TO, V^l, V^2) (->• _L 
ExistsMethodInvocation(a, TO, yi, F2) _L 
ExistsMethodInvocation(6, TO, yi,y2) i->^ _L 
IsInheritedMethodWithParains(a, TO, [f]) H> _L 
IsInheritedMethodWithParains(6, TO, [t]) i— >■ _L 
IsIndirectlyRecursive(s, to) i— >■ _L 
IsIndirectlyRecursive(a, to) ± 
IsIndirectlyRecursive(6, to) h-> _L 
IsVisibleMethod(s,TO, [t],T/l) _L 
IsVisibleMethod(a, TO, [f]. Fl) _L 
IsVisibleMethod(6, TO, [f],yi) _L 
IsInverter(s,TO, yi,y2) _L 
Islnverter(a, TO, yi, y2) _L 
IsInverter(6,TO, yi,y2) _L 
IsDelegator(s, yi, to) i-> _L 
IsDelegator(a, yi,TO) i->^ _L 
IsDelegator(&, yi, to) i— >■ _L 
IsUsedMethodIn(s, TO, yi) ± 
IsUsedMethodIii(a, TO, yi) >-> _L 
IsUsedMethodIn(6,TO, yi) _L 
IsUsedConstructorAsInitializer(yi, s, to) i->- _L 
IsUsedConstructorAsInitializer(yi, a, to) i— > X 
IsUsedConstructorAsInitializer(yi, 6, to) i-^ _L 
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IsUsedCorLStructorAsObjectReceiver(yi, s, m) i— > _L 
IsUsedConstructorAsDbjectReceiver(yi, a, to) ^ 1. 
IsUsedConstructorAsDbjectReceiver(V^l, 6, to) ^ 1. 
IsUsedAttributeInMethodBody(s, Fl, m) H> ± 
IsUsedAttributeInMethodBody(a, Fl, to) i-^ _L 
IsUsedAttributeInMethodBody(fe, T^l, to) _L 
IsOverriddeii(a. to) ± 
IsOverriddeii(6. to) _L 
IsOverloaded(s, to) i— > _L 
IsOverloaded(a, to) ± 
IsOverloaded(&, to) _L 
IsOverridiiig(a, to) _L 
IsOverridiiig(6, to) _L 
IsRecursiveMethod(s, to) k-)- _L 
IsRecursiveMethod(a, to) ^ 1. 
IsRecursiveMethod(6, to) H> _L 
HasReturnType(s, to, Vl) ± 
HasReturiiType(a, to, yi) i— >■ _L 
HasReturnType(6, to, V^l) ± 
MetliodHasParcimeterType(s, TO, yi) ± 
MetliodHasParcimeterType(a. to, VI) i— >■ _L 
MetliodHasParameterType(6, to, VI) i— > _L 
MethodIsUsedWithType(s, TO, [i], [t]) _L 
MethodIsUsedWithType(a, TO, [t], [i]) ± 
MethodIsUsedWithType(6, TO, [t], [i]) ^ ± 



A. 22 PushDownAll 



Overview: PushDownAll (classname s, attributes [attl,att2], subclasses [a,b], method m.paramType [t]) : this operation 
is used to push down the method s::ni to its subclasses and delete that method from s (in Push Down Method by 
Fowler [Fow99j . methods are not necessarily pushed down to all the subclasses). 



original code 



public abstract class S{ 
public abstract void m(){ } 



public class A extends S{ 
public void m(){ 
blockt 

} 

} 



public class B extends S{ 
public void m{){ 
block2 

} 



refactored code 



public abstract class S{ 



public class A extends S{ 
public void m(){ 
blockt 



public class B extends S{ 
public void m(){ 
block2 

} 

} 



Variation for non-abstract methods: 
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original code 



refactored code 



public abstract class S{ 



public void m(){ 

I b lockO 

} 



public class A extends S{ 
public void m{){ 
blockl 

} 

} 



public class B extends S{ 



public abstract class S{ 



public class A extends S{ 
public void m(){ 
blockl 

} 

} 



public class B extends S{ 



public void m(){ 
blockO 

} 

} 



Refactoring tools. Push Down or Push member Down in Eclipse tool and IntelliJ idea. 

Precondition. 

(Exist sClass(s) 

A IsAbstractClass(s) 

A ExistsMethodDef initionWithParams(s,m, [t]) 
A ^IsUsedMethod(s, m, [t]) 
A AllSubclasses(s, [a; b]) 
A -•IsPrivate(s, m) 

A ExistsMethodDef initionWithParajns(.s, m, [t]) 
A ExistsMethodDef initionWithParEiins(s, m, [t]) 
A -■IsPrivate(s, attl) 
A -■IsPrivate(s, att2)) 



Backward Description. 

ExistsMethodDef initionWithParams(s, TO, [<:]) i— > _L 
IsUsedMethodIn(s,TO, C) i->- _L 
ExistsMethodDef inition(s, to) i-)- _L 
ExistsAbstractMethod(.s, m) _L 
IsDelegator(,s, TO, yi) H> ± 
HasReturnType(s, TO, yi) i— ?• _L 

AllInvokedMethodsOnObjectOInBodyOf MAreDeclaredInC(s, to, VI, V2) _L 
AllInvokedMethodsWithPciraiiieterOInBodyOf MAreNotOverloaded(s, to, VI) _L 

BoundVariableInMethodBody(s, TO, VI) M> _L 
ExistsParameterWithNaine(s, to, [t], yi) i— >■ _L 
ExistsParameterWithType(s, TO, [f], yi) i->- _L 
ExistsMethodInvocation(s, TO, yi, y2) i->- _L 
IsPublic(s, to) I— > _L 
IsProtected(s, to) i— >■ _L 
IsPrivate(s, to) h- > _L 
IsOverloaded(s, to) i->- _L 

IsUsedAttributeInMethodBody(s,yi,TO) _L 
IsRecursiveMethod(s, to) i—> _L 
IsIndirectlyRecursive(s, to) i— >■ _L 
HasReturnType(s, TO, y 1) _L 
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MethodHasParaineterType(s, m, VI) _L 

MethodIsUsedWithType(s,TO, [i], [t]) i-^ _L 
IsUsedConstructorAsMethodParameter(V^l, s, to) i— >■ _L 
IsUsedConstructorAsMethodParaineter(yi, s, to) t-^ _L 
IsUsedConstructorAsObjectReceiver(Fl, s,to) i-> _L 
ExistsMethodDef initionWithParains(a, T77. [t]) i— > T 
ExistsMethodDef initionWithParains(6, to, [t]) i— >■ T 
IsOverriding(a, m) _L 
IsOverridiiig(&, to) i-^ _L 
IsOverridden(a, to) i-> _L 
IsDverridden(&, to) ?■ _L 

IsInheritedMethodWithParains(a, to, [t]) i— >■ _L 
IsInheritedMethodWithParams(6, TO, [t]) _L 
IsVisibleMethod(s, TO, [t], a) i-^- _L 
IsVisibleMethod(s, TO, [t], 6) _L 
IsVisible(s, TO, a) i— >■ _L 
IsVisible(s, TO, 6) i— >■ _L 
IsInheritedMethod(a, to) i-> _L 
IsInheritedMetliod(&, to) h-)- _L 
IsPrivate(s, attl) i— -L 
IsPrivate(s, att2) _L 



A. 23 PushDownlmplementation 

Overview: PushDownlmplementation (classname s, attributes [attl,att2], subclasses [a,b], method m,paramType [t]) : same 
as PushDownAll but keep the method abstract in the superclass. 



original code 



public abstract class S{ 



|public void m(){ 
blockO 



J>ublic class A extends S{ 
public void m(){ 
blockl 

1 

} 



public class B extends S{ 



refactored code 



public abstract class S{ 



public abstract void m() 



public class A extends S{ 
public void m(){ 
blockl 

} 

} 



public class B extends S{ 
public void m(){ 

1 blockO 

} 

} 



Precondition. 
(ExistsClass(s) 

A ExistsMethodDef inition(s, to) 

A ExistsMethodDef initionWithParains(s, to, [t]) 

A -iExistsAbstractMethod(s, to) 

A AllSubclasses(s, [a; b]) 

A -lExistsMethodDef initionWithParams(a, to, [t]) 
A -lExistsMethodDef initionWithParams(6, to, [t]) 
A -■IsPrivate(s, attl) 
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A -■IsPrivate(s, att2)) 



Backward Description. 

ExistsAbstractMethod(.s, 77?) T 

AllInvokedMethodsOnObjectOInBodyOf MAreDeclaredIiiC(s, m, VI, V2) ± 
AllInvokedMetlLodsWithPcirameterOInBodyOf MAreNotOverloaded(s, m, V^l) i— >■ _L 
BoundVariableInMethodBody(s, m, VI) i->- _L 
ExistsMethodInvocation(s, TO, V^l, F2) i-> _L 
IsInheritedMethodWithParains(s, m, [i]) h- _L 
IsIndirectlyRecursive(s, to) i— >■ _L 
IsUsedConstructorAsInitializer(yi, s, to) i->- _L 
IsUsedCoiistructorAsObjectReceiver(Fl,s,TO) i-> _L 
IsPrivate(,s, m) ^ _L 

IsUsedAttributeInMethodBody(s, yi, to) i->- _L 
IsOverriddeii(s, to) _L 
IsOverriding(s, to) i-> _L 
IsRecursiveMethod(s, to) i— >■ _L 
MethodHasParameterType(s, TO, T^l) ^ _L 
MethodIsUsedWithType(s,TO, [t], [i]) i-> _L 
ExistsMethodDef initionWithParams(a, TO, [f]) i->- T 
ExistsMethodDef initionWithParams(6, TO, [f]) T 
ExistsMethodDef inition(a, m) i— ^ T 
ExistsMethodDef inition(6, to) i-> T 
IsPrivate(s, attl) i->- _L 
IsPrivate(s, att2) i->- _L 



A. 24 PushDownNotRedefinedMethod 



pushDownNotRedefinedMethod(class c, method m) 

Duplicate the method m of class c into its subclasses. 

original code 



public abstract class S{ 
public void m(){ 
blockO 

} 

} 



public class A extends S{ 
public void m(){ 
blockl 

} 

} 



public class B extends S{ 



refactored code 



public abstract class S{ 
public void m(){ 
blocl^O 

} 

} 



public class A extends S{ 
public void m(){ 
blockl 

} 

} 



public class B ext ends Sf 
jpublic void m(){ 

I blockO 

} 

} 



Refactoring tools. Extract Method, Inline, Push Down, Rename in Eclipse and IntelliJ idea. 
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A. 25 ReplaceMethodDuplication 

Overview: ReplaceMethodDuplication (classname s, subclasses [a,b], method m,copy n, paramType [t]) : this operation 
is used to replace any occurrence of method s::m. 



original code refactored code 



public class A{ 
public void m1 {) 





public class A{ 
public void m1(){ 


blockl 

} 

public void m2(){ 




blockl 

} 

public void m2(){ 


blockl } 


>► 


this.m1(); } 


} 


} 



Refactoring tools. Replace Method Duplication in InteUiJ idea. 

Precondition. 

(ExistsClass(s) 

A ExistsMethodDef inition(s, m) 
A ExistsMethodDef inition(s, n) 

A IsDelegator(s, n, m) 
A AllSubclasses(s, [a; b])) 

Backward Description. IsUsedMethod(s, n, [t]) i— >■ _L 
IsDelegator(s, n, to) T 
ExistsMethodInvocation(s,n, s,to) i->- _L 
IsRecursiveMethod(,s, n) h-> 1_ 
IsRecursiveMethod(s, n) ^ _L 
IsRecursiveMethod(a, n) i— >■ _L 
IsRecursiveMethod(6, n) _L 

A.26 DeleteClass 

DeleteClass(class c): Delete a class c which is not used. 

Overview: DeleteClass (classname a, classnamesuperclass s ,allclasses [s,a,b], classnamemethods [m,ml],othermethods 
[m2,n]) : this operation is used to delete the class a which is supposed to be not used. 

Refactoring tools. Safe Delete in IntelliJ idea, Delete in Eclipse. 

Precondition. 

(ExistsClass(o) 

A ^ExistsMethodDef initionWitliParams(s, m2, [a]) 
A -lExistsMethodDef initionWithParams(s, n, [a]) 
A -lExistsMethodDef initionWithParams(6, m2, [a]) 
A ^ExistsMethodDef initionWithPcirams(6, n, [a]) 
A -•IsUsedMethodIn(a, to, s) 
A -■IsUsedMethodIn(a, ml, s) 
A ^IsUsedMethodIn(a, m, b) 
A ->IsUsedMethodIn(a, toI, 6) 

A -iIsUsedConstructorAsMethodParaineter(a, a, s, to2) 
A ^IsUsedConstructorAsMethodParaineter(a, a, s, n) 
A -iIsUsedConstructorAsMethodParameter(a, a, b, to2) 
A -iIsUsedConstructorAsMethodParaineter(a, a, b, n) 
A -iIsUsedConstructorAsIiiitializer(a, a, s, to2) 
A -iIsUsedConstructorAsInitializer(a, o, s, n) 
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A ^IsUsedConstructorAsInitializer(a, a, b, m2) 
A -iIsUsedConstructorAsInitializer(a, a, b, n) 
A -iIsUsedConstructorAsObjectReceiver(a, a, s, m2) 
A -iIsUsedConstructorAsObjectReceiver(a, a, s, n) 
A -iIsUsedConstructorAsObjectReceiver(a, a, 6, rn2) 
A -iIsUsedConstructorAsObjectReceiver(a, a, b, n) 
A -iIsSubType(s, a) 
A -iIsSubType^feja)) 

Backward Description. 

ExistsType(a) i— >■ _L 
IsSubType(a, s) _L 

AllInvokedMethodsOnObj ectOInBodyOf MAreDeclaredInC(a, VI, V2, V3) ^ _L 
AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(a, VI, V2) _L 
BouiidVariableInMethodBody(a, Vl, F2) _L 
ExistsParameterWitliNaine(a, yi,[V'2],T/3) _L 
ExistsParameterWithType(a, yi, [F2],F3) ^ _L 
ExistsField(a, 1^1) ^ L 

ExistsMethodInvocation(a, F2, F3) ^ L 
ExistsMethodDef initionWithParains(a, Fl, [1^2]) i-> _L 
ExteiidsDirectly(a, s) i->- _L 
ExtendsDirectly(yi, a) ^ _L 
ExistsAbstractMethod(a, VI) ^ ± 
IsInheritedMethodWithParams(a, Fl, [V2]) ^ _L 
IsIndirectlyRecursive(a, VI) ^ ± 
IsVisibleMethod(a,Vl, [y2],F3) i-^ _L 
Islnverter(a, VI, V2, V3) >-> _L 
IsDelegator(a, VI, V2) H- _L 
IsAbstractClass(a) i— )■ _L 
IsUsedMethod(a, VI, [V2]) i-^- _L 
IsUsedMethodIn(a, VI, V2) ^ _L 

IsUsedConstructorAsMethodParameter(Vl, a, V2) _L 
IsUsedConstructorAsInitializer(a, VI, V2) i— >■ _L 
IsUsedConstructorAsObjectReceiver(a, VI, V2) _L 
IsUsedConstructorAsInitializer(Vl, a, V2) i->- _L 
IsUsedConstructorAsObjectReceiver(Vl, a, V2) >->• _L 
IsPrimitiveType(a) i— >■ _L 
IsPublic(a, VI) _L 
IsProtected(a, VI) _L 
IsPrivate(a, VI) H> ± 

IsUsedAttributeIiiMethodBody(a, VI, V2) i-)- _L 
IsGenericsSubtype(a, [VI], .s, [V2]) n> _L 
IsGenericsSubtype(Vl, [V2],o, [V3]) _L 
IsGenericsSubtype(Vl, [a], V2, [V3]) ^ _L 
IsInheritedField(a, VI) ^ _L 
IsOverridden(a, VI) i— > _L 
IsOverloaded(a, VI) _L 
IsOverriding(a, VI) i-> _L 
IsRecursiveMethod(a, VI) i— t- _L 
IsRecursiveMethod(a, VI) H> ± 
HasReturiiType(a, VI, V2) i-^ _L 
HasParameterType(a, VI) ^ _L 
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HasParameterType(yi, a) _L 

MethodHasParameterType(a, VI, F2) ± 
MethodIsUsedWithType(a, VI, [V2], [V3]) H- ± 
MethodIsUsedWithType(Vl, V2, [a], [a]) ^ _L 
ExistsMethodDef inition(a, m) i-> ± 
ExistsMethodDef inition(a, ml) h- > _L 
IsIiilieritedMet]iodWithParains(Vl,TO, [V2]) i-^ _L 
IsInheritedMethodWithParams(Vl,TOl, [V2]) H> _L 



A.27 ExtractGeneralMethod 
original code 



public abstract class C{ 

public void ma(){ 
new A().op(this); 

} 

public void mb(){ 
new B().op(this); 



public class S{ 
public void op(C c){...} 

} 



public class A extends S{ 



public class B extends S{ 



refactored code 



public abstract class C{ 



public void m(S o){ 
o.op(this); 



public void ma(){ 
I m(new AQjTl 



public void mb (){ 



m(new BQ); 



public class S{ 
public void op(C c){...} 

} 



public class A extends S{ 



public class B extends S{ 



A. 28 InlineClass 

lnlineClass(class c): Inline one or more references to a given class c. 
Refactoring tools. Inline in Eclipse and IntelliJ idea. 
A. 29 SpecialiseParameter 

Overview: SpecialiseParameter(classname s, subclasses [a,b], methodname m.paramType t .paramName p, subtypes [st,q],new param 
Type St): this operation is used to change the type t of the parameter p of the methods s::m, a::m and b::m into one of 
its subtypes (st). 

Precondition. 

(IsSubType(.st,i) 

A -.MethodIsUsedWithType(s, m, [t], [t]) 
A -■MethodIsUsedWithType(a,m, [t], [t]) 
A ^MethodIsUsedWithType(6,m, [t], [t]) 
A ExistsClass(s) 

A ExistsMethodDef initionWithParams(s,m, [t]) 
A ExistsType(t) 
A ExistsType(st) 
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A ^ExistsMethodDef iiiitioiiWithParams(s, m, [st]) 
A ^IsIiilieritedMetliodWithParcims(s, m, [st]) 
A AllSubclasses(s, [a; b]) 

A AllInvokedMethodsWithParameterOInBodyOf MAreNotOverloaded(s, m, p) 

A (-iMethodIsUsedWithType(s, m, [t], [q]) V ExistsMethodDef initionWithParams(s, m, [q]))) 

Backward Description. 

ExistsMethodDef initionWithParains(s, m, [st]) i— > T 
ExistsMethodDef initionWithParains(s, m, [i]) M> ± 
ExistsMethodDef initionWithParains(a, m, [t]) H- _L 
ExistsMethodDef initionWithParains(6, m, [t]) M> ± 

ExistsMethodDef initionWithParains(a, rn, [st]) h- > ExistsMethodDef initionWithParajns(a, m, [t]) 

ExistsMethodDef initionWithParains(6, rn, [st]) i— ^ ExistsMethodDef initionWithParajns(6, m, [t]) 

MethodIsUsedWithType(s, rn, [t], [t]) _L 

MethodIsUsedWithType(a, m, [t], [t]) ± 

MethodIsUsedWithType(fe, m, [t], [t]) ^ ± 

ExistsParameterWithNaine(s, TO, [st],p) M- T 

ExistsParameterWithNaine(a, TO, [st],p) ^ T 

ExistsParameterWithNaine(6, TO, [st],p) ^ T 

ExistsParameterWithType(s, TO, [si], st) M> T 

ExistsParameterWithType(a, TO, [st], st) i— >■ T 

ExistsParameterWithType(6, TO, [st], st) i— >■ T 

Islnverter(s, TO, st, t^) M> Islnverter(s, to, t, y) 

Islnverter(a, TO, st, ]/) ^ Islnverter(a, to, t, V^) 

Islnverter(6, TO, st, ]/) ^ Islnverter(6, to, t, y) 

IsInheritedMethodWithParains(s, TO, [st]) i—> T 

IsInheritedMethodWithPEirams(a, TO, [st]) ^ T 

IsInheritedMethodWithPcirains(6, TO, [st]) H> T 

IsUsedConstructorAsMethodParameter(st, s, m) H> T 

IsUsedConstructorAsMethodParameter(st, a, to) H> T 

IsUsedConstructorAsMethodParameter(st, 6, to) i— ^ T 

IsUsedConstructorAsMethodPEirameter(t, s, to) H> _L 

IsUsedConstructorAsMethodParameter(t, a, to) ^ ± 

IsUsedConstructorAsMethodParameter(t, 6, to) i— ;> _L 

IsDverridden(a, m) t-^ ExistsMethodDef inition(a, to) 

IsDverridden(6, to) M> ExistsMethodDef inition(6, to) 

IsDverriding(a, to) M> ExistsMethodDef inition(a, to) 

IsDverriding(&, to) ExistsMethodDef inition(6, to) 

B Preconditions composition 

In this section, we apply a calculus of minimal precondition to the sequence of basic refactoring operations that compose 
our transformation. We apply the calculus of Kniesel and Koch [KK04] . based on the backward descriptions given 
in the previous appendix. We use that calculus to compute a minimum precondition that ensures that the round-trip 
transformation succeeds, which means we determine a set of programs on which we can ensure that the preconditions of all 
the component refactoring operations will be satisfied when applying the Composited Visitor ^ Composite transformation 
any number of time (as explained in [CA13| ). 

That computed precondition is given in Fig. 1291 The chains taken into account for the computation are given in 
Figs. [57] and UHl The difference between these chains and the algorithms of previous sections are: 

• We add some parameters to the operations that were not made explicit before (in previous sections, the project was 
an implicit parameter). 
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• Composite operations are replaced by their component operations (MergeDuplicateMethods in step 8 of the Com- 
posited Visitor chain). 

• Wc split some operations of the tool into several abstract operations when the behavior of an operation depends 
on the state of the program. In that case, each possible behavior is represented by a different abstract operation. 
For instance, we have two operations for method renaming, one for overloaded methods and one for not-overloaded 
methods. 

1. CreateEmptyClass(PrintVisitor) 
CreateEmptyClass(PrettyprintVisitor) 

2. CreatelndirectionlnSuperClass(Graphic,[Ellipse;CompositeGraphic;], print, [], void, printTmpVC) 
CreatelndirectionlnSuperClass(Graphic, [Ellipse;CompositeGraphic;], prettyprint, [], void, prettyprintTmpVC) 

3. lnlineMethodlnvocations(CompositeGraphic, printTmpVC, [], Graphic, print, []) 
lnlineMethodlnvocations(CompositeGraphic, prettyprintTmpVC, [], Graphic, prettyprint, []) 

4. AddParameterWithReuse(Graphic, [Ellipse;CompositeGraphic;], printTmpVC, [], PrintVisitor, v) 
AddParameterWithReuse(Graphic, [Ellipse;CompositeGraphic;], prettyprintTmpVC, [], PrettyprintVisitor, v) 

5. MoveMethodWithDelegate (Ellipse, [mChildGraphics;], PrintVisitor, printTmpVC, [PrintVisitor;], void, visit) 
MoveMethodWithDelegate (CompositeGraphic, [mChildGraphics;], PrintVisitor, printTmpVC, [PrintVisitor;], void, 

visit) 

MoveMethodWithDelegate (Ellipse, [mChildGraphics;], PrettyprintVisitor, prettyprintTmpVC, [PrettyprintVisitor;], 
void, visit) 

MoveMethodWithDelegate (CompositeGraphic, [mChildGraphics;], PrettyprintVisitor, prettyprintTmpVC, [Pret- 
typrintVisitor;], void, visit) 

6. ExtractSuperClass ([PrintVisitor;PrettyprintVisitor;], Visitor, [visit;], void) 

7. GeneraliseParameter (Graphic, [Ellipse;CompositeGraphic;], printTmpVC, v, PrintVisitor, Visitor) 
GeneraliseParameter (Graphic, [Ellipse;CompositeGraphic;], prettyprintTmpVC, v, PrettyprintVisitor, Visitor) 

8. ReplaceMethodcodeDuplicateslnverter (Ellipse, printTmpVC, [prettyprintTmpVC;], Visitor, void) 
ReplaceMethodcodeDuplicateslnverter (CompositeGraphic, printTmpVC, [prettyprintTmpVC;], Visitor, void) 
PullupConcreteDelegator (Ellipse, [mChildGraphics;], prettyprintTmpVC, Graphic) 
SafeDeleteWithOverridden (CompositeGraphic, prettyprintTmpVC, Graphic) 

InlineAndDelete (Graphic, prettyprintTmpVC) 

RenamelnHierarchyNoOverloading (Graphic, [Ellipse;CompositeGraphic;], printTmpVC, [Visitor;], accept) 

Figure 27: Chain of refactoring operations for Composite— >■ Visitor transformation analysis 
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1. DuplicateMethodlnHierarchy (Graphic, [Ellipse;CompositeGraphic;], accept, [visit;], [print;prettyprint;], acceptPrint- 
VisitoraddspecializedMethodtmp, [Visitor;]) 

SpecialiseParameter (Graphic, [Ellipse;CompositeGraphic;], acceptPrintVisitoraddspecializedMethodtmp, Visitor, 

[PrintVisitor;PrettyprintVisitor;], PrintVisitor) 

RenameDelegatorWithOverloading (Graphic, [Ellipse;CompositeGraphic;], acceptPrintVisitoraddspecialized- 
Methodtmp, PrintVisitor, v, Visitor, accept) 

DuplicateMethodlnHierarchy (Graphic, [Ellipse;CompositeGraphic;], accept, [visit;], [print;prettyprint;], acceptPret- 
typrintVisitoraddspecializedMethodtmp, [Visitor;]) 

SpecialiseParameter (Graphic, [Ellipse;CompositeGraphic;], acceptPrettyprintVisitoraddspecializedMethodtmp, Visi- 
tor, [PrintVisitor; PrettyprintVisitor;], PrettyprintVisitor) 

RenameDelegatorWithOverloading (Graphic, [Ellipse;CompositeGraphic;], acceptPrettyprintVisitoraddspecialized- 
Methodtmp, PrettyprintVisitor, v, Visitor, accept) 

DeleteMethodlnHierarchy (Graphic, [Ellipse;CompositeGraphic;], accept, [visit;], Visitor) 

2. PushDownAII (Visitor, [PrintVisitor;PrettyprintVisitor;], visit, [Ellipse;]) 
PushDownAII (Visitor, [PrintVisitor;PrettyprintVisitor;], visit, [CompositeGraphic;]) 

3. InlineMethod (Ellipse, visit, PrintVisitor, accept) 
InlineMethod (CompositeGraphic, visit, PrintVisitor, accept) 
InlineMethod (Ellipse, visit, PrettyprintVisitor, accept) 
InlineMethod (CompositeGraphic, visit, PrettyprintVisitor, accept) 

4. RenameOverloadedMethodlnHierarchy (Graphic, [Ellipse;CompositeGraphic;], accept, printTmpVC, [PrintVisitor;]) 

RenameOverloadedMethodlnHierarchy (Graphic, [Ellipse;CompositeGraphic;], accept, prettyprintTmpVC, [Pret- 
typrintVisitor;]) 

5. RemoveParameter (Graphic, [Ellipse;CompositeGraphic;], printTmpVC, [PrintVisitor;], PrintVisitor, v) 
RemoveParameter (Graphic, [Ellipse;CompositeGraphic;], prettyprintTmpVC, [PrettyprintVisitor;], PrettyprintVisitor, 

v) 

6. ReplaceMethodDuplication (Graphic, [Ellipse;CompositeGraphic;], print, printTmpVC, []) 
ReplaceMethodDuplication (Graphic, [Ellipse;CompositeGraphic;], prettyprint, prettyprintTmpVC, []) 

7. PushDownlmplementation (Graphic, [], [Ellipse;CompositeGraphic;], print, []) 
PushDownlmplementation (Graphic, [], [Ellipse;CompositeGraphic;], prettyprint, []) 

8. PushDownAII (Graphic, [Ellipse;CompositeGraphic;], printTmpVC, []) 
PushDownAII (Graphic, [Ellipse;CompositeGraphic;], prettyprintTmpVC, []) 

9. InlineAndDelete (Ellipse, printTmpVC) 

InlineAndDelete (CompositeGraphic, printTmpVC) 
InlineAndDelete (Ellipse, prettyprintTmpVC) 
InlineAndDelete (CompositeGraphic, prettyprintTmpVC) 

10. DeleteClass (PrintVisitor, Visitor, [Ellipse;CompositeGraphic;PrintVisitor;PrettyprintVisitor;Visitor;Graphic;], [visit;], 
[accept;eval;show;]) 

DeleteClass (PrettyprintVisitor, Visitor, [Ellipse;CompositeGraphic;PrintVisitor;PrettyprintVisitor;Visitor;Graphic;], 
[visit;], [accept;eval;show;]) 

11. DeleteClass (Visitor, java.lang.Object, [Ellipse;CompositeGraphic;PrintVisitor;PrettyprintVisitor;Visitor;Graphic;], 
[visit;], [accept;eval;show;]) 

Figure 28: Chain of refactoring operations of the back transformation analysis 
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(-iExistsMethodDefinition( Grap/i-ic, accept) 

A -lExistsMethodDef initioii(ii^^?zpse, accept) 

A -•ExistsMethodDefinition( CompositeGrop/iic, accept) 

A -iIsInheritedMethod( Graphic, accept) 

A AllInvokedMethodsWithParameterOInBodyOfMAreNotDverloaded(GompositeGrap/iic, prettyprmt, this) 
A AllInvokedMethodsOnObjectOInBodyOfMAreDeclaredInC(£'/Zipse, prettyprint, this, Graphic) 
A AllInvokedMethodsWithParameterOInBodyOfMAreNotOverloaded(SZZipse, prettj/prmt, this) 
A -^Ex±stsType(V isitor) 
A ExistsCla.ss{Ellipse) 

A -iBoundVariableInMethodBody( Grap/iic, prettyprint, v) 

A -iBoundVariableInMethodBody(Grapft.'ic, print, v) 

A lsKecnTsivenetiiod{CompositeGraphic, prettyprint) 

A Ex±stsClaiSs{C ompositeGraphic) 

A IsRecur slveKethodlC ompositeGraphic, print) 

A ExistsMethodDef initionWithParajns(Grapft.«c, prettt/print, []) 

A ExistsAbstractMethod(Grap/iic, prettyprint) 

A ^ I s Inher it edMethod( Grap/iic, prettyprintTmpVG) 

A -ilsliiheTite<Meth.od\litlaPaiam.s{Graphic,prettyprintTrnpVG, []) 

A -lExistsMethodDef initionWithParaiiis(Grapft.ic, prettyprmtTmpyG, []) 

A HasReturnType(Grapft.ic, prettyprint, void) 

A ExistsMethodDef inition( Grap/iic, prettyprint) 

A ExistsMethodDefinition(i<^/Zipse, prettyprint) 

A ExistsMethodDefinition(GompositeGrap/iic, prettyprint) 

A -iExistsMethodDefinition( Grap/iic, prettyprintTm.pVG) 

A -^Existsl'lethodT)efinitioiL{Ellipse, prettyprintTmpVG) 

A -^ExistsVleth.od'DefiiLition{CompositeGraphic, prettyprintTmpVG) 

A ExistsClass(Grap/iic) 

A IsAbstractClass(Grap/iic) 

A ExistsMethodDefinitionWithParcmis(Grap/iic, print, []) 

A ExistsAbstractMethod(Grap/iic, print) 

A -iIsInheritedMethod( Grapft-ic, printTmpVG) 

A ^IsInheritedMethodWithParcfflis(Grap/iic, printTmpVG, []) 

A -iExistsMethodDefiiiitionWithParams(Grapft.ic, printTmpVG, []) 

A AllSubclasses(Grap/iic, [Ellipse; GompositeGraphic]) 

A HasReturnType(Grap/iic, print, void) 

A -iIsPrivate(Grap/iic, print) 

A -ilsPTiva.te{Ellipse, print) 

A -iIsPrivate(GompositeGrap/iic, print) 

A ExistsMethodDefinitioii( Graphic, print) 

A ExistsMethodDefinition(£'/Zip.se, print) 

A ExistsMethodDefinition(Gom,positeGrap/iic, print) 

A -iExistsMethodDefinition(Grap/iic, printTmpVG) 

A -iExistsMethodDefinitioii(i?^Zipse, printTmpVG) 

A ^ExistsMethodDefinition(GompositeGrap/iic, printTmpVG) 

A -iExistsType(Prettyprint Visitor) 

A -■ExistsType(PrintVisitor)) 

Figure 29: Computed precondition for the round-trip transformation 
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